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Introduction 


This publication contains copies of the material presented at the Second NASA Langley 
Formal Methods Workshop held at the NASA Langley Research Center August 11-13, 1992. 
The purpose of the workshop was to bring together formal methods researchers and aerospace 
industry engineers to investigate new opportunities for applying formal methods to aerospace 
problems. The first part of the workshop was tutorial in nature. The second part of the 
workshop explored the potential of formal methods to solve current aerospace design and 
verification problems. The third part of the workshop involved on-line demonstrations of 
state-of-the-art formal verification tools. Finally, a detailed survey was filled in by the 
attendees; the results of the survey are compiled in this report. 

The workshop was attended by aerospace industry engineers and managers, interested 
government representatives from FAA, NSA, NCSC, and DARPA, NASA Langley formal- 
methods contractors, university professors, and NASA personnel. A list of attendees is 
included in this publication. 
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N93-12958 

A Brief Overview of NASA Langley’s 
Research Program in Formal Methods 

System Validation Methods Branch 
NASA Langley Research Center 
Hampton, Virginia 

September 21, 1992* 


Abstract 

This paper presents an overview of NASA Langley’s research program in formal methods. 
The major goal of this work is to bring formal methods technology to a sufficiently mature 
level for use by the United States aerospace industry. Towards this goal, work is under- 
way to design and formally verify a fault- tolerant computing platform suitable for advanced 
flight control applications. Also several direct technology transfer efforts have been initiated 
that apply formal methods to critical subsystems of real aerospace computer systems. The 
research team consists of six NASA civil servants and contractors from Boeing Military Air- 
craft Company, Computational Logic Inc., Odyssey Research Associates, SRI International, 
University of California at Davis, and Vigyan Inc. 


Motivation 

NASA Langley Research Center has been developing techniques for the design and validation 
of flight critical systems for over two decades. Although much progress has been made in 
developing methods which can accommodate physical failures, the design flaw remains a 
serious problem [2, 3, 4, 5, 6, 7, 8]. 

A recent report by the National Center For Advanced Technologies has identified Prov- 
ably Correct System Specification” and “Verification Formalism For Error-Free Specifica- 
tion” as key areas of research for future avionics software and ultrareliable electronics systems 
[9]. Aerospace engineers attending the NASA-LaRC Flight Critical Digital Systems Tech- 
nology Workshop [10] listed techniques for the validation of concurrent and fault-tolerant 
computer systems high on the list of research priorities for NASA. 

•This is an updated version of the a paper entitled “NASA Langley’s Research Program in Formal 

Methods” presented at COMPASS 91 [1]. . , 

1 A technical council funded by the Aerospace Industries Association of America ( AIA) that represents the 
major U.S. aerospace companies engaged in the research, development and manufacture of aircraft, missiles 
and space systems and related propulsion, guidance, control and other equipment. 
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A further motivation for the use of formal methods is the practical limitations of life- 
testing methods to quantify reliability in the ultrareliable domain. Unfortunately, the quan- 
tification of reliability in the presence of design faults has been found to be infeasible whether 
applied to hardware or software (standard or fault-tolerant) [11]. Therefore the use of non- 
statistical method is necessary. 


Formal Methods 

Formal methods are the applied mathematics of computer systems engineering. There are 
many different types of formal methods with various degrees of rigor. The following is a 
useful (first-order) taxonomy of the degrees of rigor in formal methods: 

Level-1: Formal specification of all or part of the system. 

Level-2: Formal specification at two or more levels of abstraction and paper and 
pencil proofs that the detailed specification implies the more abstract spec- 
ification. 

Level-8: Formal proofs checked by a mechanical theorem prover. 

Level 1 represents the use of mathematical logic or a specification language that has a 
formal semantics to specify the system. This can be done at several levels of abstraction. 
For example, one level might enumerate the required abstract properties of the system, 
while another level describes an implementation which is algorithmic in style. Level 2 for mal 
methods goes beyond level 1 by developing pencil- and- paper proofs that the m ore concrete 
levels logically imply the more abstract-property oriented levels. Level 3 is the most rigorous 
app licat ion of formal methods. Here one uses a semi-automatic theorem prover to make sure 
that all of the proofs are valid. The Level 3 process of convincing a mechanical prover is 
really a process of developing an argument for an ultimate skeptic who must be shown every 
detail. 

It is also important to realize that formal methods is not an all-or-nothing approach. 
The application of formal methods to the most critical portions of a system is a pragmatic 
and useful strategy. Although a complete formal verification of a large complex system is 
impractical at this time, a great increase in confidence in the system can be obtained by the 
use of formal methods at key locations in the system. 


Research Team 

The Langley formal methods program involves both in-house researchers and industrial/academic 
researchers working under contract to NASA Langley. Currently the in-house team consists 
of six civil servants and one in-house contractor (Vigyan Inc.). NASA Langley has awarded 
three contracts specifically devoted to formal methods (from the competitive NASA RFP 
1-22-9130.0238). The selected contractors were SRI International, Computational Logic 
Inc., and Odyssey Research Associates. The three contracts are five-year, task assignment 
contracts with total spending authority at approximately $2.5M per contract. Another 
task-assignment contract with Boeing Military Aircraft Company (BMAC) is being used to 
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explore formal methods as well. Through this contract BMAC is funding research at the 
University of California at Davis and California Polytechnic State University to assist them 
in the use of formal methods in aerospace applications. 

NASA Langley’s Research Strategy 

The basic strategy of the research effort is to apply existing formal methods to challenging 
aerospace designs. This strategy leverages the huge investment of DARPA and National 
Security Agency in development of tools and concentrates on the problems specific to the 
aerospace problem domain. We have sought to build a strong inhouse research program 
as well as use contracts with the leading U.S. formal methods research teams (i.e. SRI, 
CLI, ORA) and aerospace industrial teams (BMAC, Draper Labs). In the short term we 
are seeking to apply formal methods to critical subsystems. In the medium term we are 
designing and verifying a reliable computing platform. Only in the long-term will we seek to 
make production-quality verification tools that are easily used by design engineers without 
overly specialized, detailed knowledge of formal methods. 

The design of a digital flight control system involves two dissimilar activities: 

1. design and implementation of control laws 

2. design of the fault- tolerant computing platform which executes the control laws 

Although these design activities are intimately connected, they require uniquely different 
skills. The first activity requires knowledge of feedback control theory and aerodynamics as 
well as numerical methods. The second activity requires knowledge of fault-tolerance theory 
and computer architecture. Although both activities are essential, we are concentrating at 
this time on the second activity. To facilitate the development and demonstration of tools 
and techniques to support the second activity, a reliable computing platform (RCP) is being 
developed. Also, several tasks are underway to facilitate the transfer of formal methods 
technology to aerospace industry. 

The Reliable Computing Platform 

The Reliable Computing Platform (RCP) dispatches the control-law application tasks and 
executes them on redundant processors. The reliable computing platform performs the 
necessary fault-tolerant functions and provides an interface to the network of sensors and 
actuators. 

The RCP consists of both hardware and software components. A real-time operating sys- 
tem provides the applications software developer with a reliable mechanism for dispatching 
periodic tasks on a fault-tolerant computing base that appears to him as a single ultra- 
reliable processor. Traditionally, an operating system has been implemented as an executive 
(or main program) that invokes subroutines implementing the application tasks. Commu- 
nication between the tasks has been accomplished by use of shared memory. This strategy 
is effective for systems with nominal reliability requirements where a simplex processor can 
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be used. For ultra-reliable systems, the additional responsibility of providing fault tolerance 
makes this approach untenable. 

For these reasons, the operating system and replicated computer architecture must be 
designed together so they mutually support the goals of the RCP. A multi-level hierarchical 
specification of the RCP is shown in figure 1. 



Figure 1: Hierarchical Specification of the Reliable Computing Platform (RCP) 

The top level of the hierarchy describes the operating system as a function that sequen- 
tially invokes application tasks. This view of the operating system will be referred to as the 
uniprocessor specification (US), which is formalized as a state transition system and forms 
the basis of the specification for the RCP. Fault tolerance is achieved by voting results com- 
puted by the replicated processors operating on the same inputs. Interactive consistency 
checks on sensor inputs and voting of actuator outputs require synchronization of the repli- 
cated processors. The second level in the hierarchy (RS) describes the operating system as 
a synchronous system where each replicated processor executes the same application tasks. 
The existence of a global time base, an interactive consistency mechanism and a reliable 
voting mechanism are assumed at this level. Level 3 of the hierarchy breaks a frame into 
four sequential phases. This allows a more explicit modeling of interprocessor communica- 
tion and the time phasing of computation, communication, and voting. At the fourth level, 
the assumptions of the synchronous model must be discharged. Rushby and von Henke [12] 
report on the formal verification of Lamport and Melliar-Smith’s [13] interactive-convergence 
clock synchronization algorithm. This algorithm can serve as a foundation for the implement 
tation of the repficated system by bounding the amount of asynchrony in the system so that 
it can duplicate the functionality of the DS model. Dedicated hardware implementations of 
the clock synchronization function are a long-term goal. The LE model is currently under 
development. This model describes the actions on each local processor delineating how each 
processor schedules tasks, votes results and rewrites its own local memory with voted val- 
ues. Of primary importance in this specification is the utilization of a memory management 
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unit by the local executive in order to prevent the overwriting of incorrect memory loca- 
tions while recovering from the effects of a transient fault. There will probably be another 
level of specification introduced before the final implementation in hardware and software is 
reached. The research activity will culminate in a detailed design and prototype implemen- 
tation. Figure 2 depicts the generic hardware architecture assumed for implementing the 
replicated system. Single-source sensor inputs are distributed by special purpose hardware 
executing a Byzantine agreement algorithm. Replicated actuator outputs are all delivered 
in parallel to the actuators, where force-sum voting occurs. Interprocessor communication 
links allow replicated processors to exchange and vote on the results of task computations. 
As previously suggested, clock synchronization hardware may be added to the architecture 
as well. 

The hardware architecture is a classic N-modular redundant (NMR) system with a small 
number N of processors. Single-source sensor inputs are distributed by special purpose 
hardware executing a Byzantine agreement algorithm. Replicated actuator outputs are all 
delivered in parallel to the actuators, where force-sum voting occurs. Interprocessor com- 
munication links allow replicated processors to exchange and vote on the results of task 
computations. This is illustrated in figure 2. 
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f igure 2: Generic hardware architecture. 


The Division of Labor 

The in-house team at NASA has been orchestrating the effort to apply formal methods to 
the RCP. The design problem has been decomposed into several separate activities, some of 
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which are being investigated by contractual teams and others by the in-house team. The 
efforts are roughly divided as follows: 


in-house: 

SRI: 

CLI: 

ORA: 

BMAC: 


system architecture, clock synchronization 
Clock synchronization, fault- tolerance 
Byzantine Agreement Circuits, clock synchronization 
Byzantine Agreement Circuits, applications 
Hardware Verification, formal requirements analysis 


NASA In-house Work 

The in-house team has concentrated on the system architecture for the RCP. The top two 
levels of the RCP were originally formally specified in standard mathematical notation and 
connected via mathematical (i.e. level 2 formal methods) proof[14, 15]. Under the assump- 
tion that a majority of processors are working in each frame, the proof establishes that the 
replicated system computes the same results as a single processor system not subject to fail- 
ures. Sufficient conditions were developed that guarantee that the replicated system recovers 
from transient faults within a bounded amount of time. SRI subsequently generalized the 
models and constructed a mechanical proof in Ehdm [16]. Next, the NASA inhouse team 
developed the third and fourth level models. The top two levels and the two new models 
were then specified in Ehdm and all of the proofs were done mechanically using the Ehdm 
5.2 prover [17, 18] 

Inhouse work is underway to design and implement a fault-tolerant clock synchronization 
circuit capable of recovery from transient faults [19, 20]. The circuit is being implemented 
using programmable logic devices (PLDs) and FOXI fiber optic communications chips [21]. 


Contractual Efforts 

SRI International 

The redundancy management strategies of virtually all fault-tolerant systems depend upon 
some form of voting which in turn depends upon synchronization. Although in many systems 
the clock synchronization function has not been decoupled from the applications (e.g. the 
redundant versions of the applications synchronize by messages), research and experience 
have led us to believe that solving the synchronization problem independently from the ap- 
plications design can provide significant simplification of the system [22, 23]. The operating 
system is built on top of this clock-synchronization foundation. Of course, the correctness 
of this foundation is essential. Thus, the clock synchronization algorithm and its implemen- 
tation are prime candidates for formal methods. The verification strategy shown in figure 3 
is being explored. The top-level in the hierarchy is an abstract property of the form: 

V non-faulty p, q : |C p (f) — ( 7 ,(<)| < 6 

where 6 is the maximum clock skew guaranteed by the algorithm as long as a sufficient 
number of clocks (and the processors they are attached to) are working. The function C p (t) 
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Digital Circuit Implementation 


Figure 3: Hierarchical Verification of Clock Synchronization 


gives the value of clock p at real time t. The middle level in the hierarchy is a, mathematical 
definition of the synchronization algorithm. The bottom level is a detailed digital design of 
a circuit that implements the algorithm. The bottom level is sufficiently detailed to make 
translation into silicon straight forward. 

The verification process involves two important steps: (1) verification that the algorithm 
satisfies the maximum skew property and (2) verification that the digital circuitry correctly 
implements the algorithm. The first step has already been completed by SRI International. 
The first such proof was accomplished during the design and verification of SIFT [13]. The 
proof was done by hand in the style of most journal proofs. More recently this proof step 
has been mechanically verified using the Ehdm theorem prover [12]. In addition, SRI has 
mechanically verified Schneider’s clock synchronization paradigm [24] using Ehdm[25]. A 
further generalization was found at NASA Langley [20] 2 . The design of a digital circuit to 
distribute clock values in support of fault- tolerant synchronization has been completed by 
SRI International and is currently being formally verified. 3 

SRI is currently writing a chapter for the FAA Digital Systems Validation Handbook 
Volume III on formal methods[26]. The handbook provides detailed information about digital 
system design and validation and is used by the FAA certifiers. 

Computational Logic Inc. 

Fault-tolerant systems, although internally redundant, must deal with single-source informa- 
tion from the external world. For example, a flight control system is built around the notion 
of feedback from physical sensors such as accelerometers, position sensors, pressure sensors, 
etc. Although these can be replicated (and they usually are), the replicates do not produce 
identical results. In order to use bit-by-bit majority voting all of the computational repli- 
cates must operate on identical input data. Thus, the sensor values (the complete redundant 
suite) must be distributed to each processor in a manner which guarantees that all working 
processors receive exactly the same value even in the presence of some faulty processors. 
This is the classic Byzantine Generals problem [27]. CLI is investigating the formal verifica- 

2 The bounded delay assumption was shown to follow from the other assumptions of the theory. 

3 Unlike the NASA inhouse circuit, the SRI intent is that the convergence algorithm be implemented in 

software. 
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tion of such algorithms and their implementation. They have formally verified the original 
Marshall, Shostak, and Lamport version of this algorithm using the Boyer Moore theorem 
prover [28]. They have also implemented this algorithm down to the register-transfer level 
and demonstrated that it implements the mathematical algorithm [29] and then subsequently 
verified the design down to a hardware description language (HDL) developed at CLI [30]. 

CLI has reproduced the SRI verification of the interactive convergence algorithm using the 
Boyer-Moore theorem prover [31]. CLI has also developed a formal model of asynchronous 
communication and demonstrated its utility by formally verifying a widely used protocol for 
asynchronous communication called the bi-phase mark protocol, also known as “Bi-$-M,” 
“FM” or “single density” [32]. It is one of several protocols implemented by microcontrollers 
such as the Intel 82530 and is used in the Intel 82C501 AD Ethernet Serial Interface. 


Odyssey Research Associates 

ORA has also been investigating the formal verification of Byzantine Generals algorithms. 
They have focused on the practical implementation of a Byzantine-resilient communications 
mechanism between Mini-Cayuga micro-processors [33, 34, 35]. The Mini-Cayuga is a small 
but formally verified microprocessor developed by ORA. It is a research prototype and 
has not been fabricated. The communications circuitry would serve as a foundation for a 
fault-tolerant architecture. It was designed assuming that the underlying processors were 
synchronized (say by a clock synchronization circuit). The issues involved with connecting 
the Byzantine communications circuit with a clock synchronization circuit and verifying the 
combination has not yet been explored. - ' ; 

Another task that has been started with ORA is to apply their Ada verification tools to 
aerospace applications. This effort consists of two subtasks. The first subtask is to verify 
some utility routines obtained from the NASA Goddard Space Flight Center and the NASA 
Lewis Research Center using their Ada Verification Tool named Penelope [36]. This subtask 
was accomplished in two steps: (1) a formal specification of the routines and (2) formal 
verification of the routines. Both steps uncovered errors in the routines [37]. The second 
subtask was to formally specify the mode-control panel logic of a Boeing-737 experimental 
aircraft system using Larch (the specification language used by Penelope) [38]. 

A joint project between ORA and Charles Stark Draper Laboratory (CSDL) has been 
initiated. The CSDL has been funded by NASA Langley to build fault-tolerant computer 
systems for over two decades. They have recently become interested in the use of formal 
methods to increase confidence in their designs. ORA has formally specified an important 
circuit (called the scoreboard) of the Fault-Tolerant Parallel Processor (FTPP) [39] in Cal- 
iban [40]. Work is currently underway to formally verify the circuit. 


Boeing Military Aircraft Co. 

The Boeing Company has been sponsored by NASA Langley to develop advanced validation 
and verification techniques for fly-by-wire systems. As part of the project, Boeing is exploring 
the use of formal methods. The goal of this work is two-fold: 1) technology transfer of formal 
methods to Boeing, and 2) assessment of formal methods technology maturity. 
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NASA Langley has been involved in a cooperative research partnership with Boeing to 
facilitate the acceptance and adoption of this high-risk, high-payoff technology by Boeing. 
The first step was to demonstrate that formal verification of “real” hardware devices is, in 
fact, feasible. The first Boeing tasks concentrated on applying the HOL hardware verification 
methodology to a set of hardware devices. With the assistance of a subcontract with U. C. 
Davis, Boeing verified a set of hardware devices, including a microprocessor [41], a floating- 
point coprocessor similar to the Intel 8087 but smaller[42, 43], a direct memory access (DMA) 
controller similar to the Intel 8237A but smaller [44], and a set of memory- management 
units[45, 46]. U. C. Davis also developed the generic-interpreter theory to aid in the formal 
specification and verification of hardware devices[47, 48, 49], and a horizontal-integration 
theory for composing verified devices into a system [50, 51, 52, 53]. 

After demonstrating the feasibility of verifying standard hardware devices, Boeing was 
ready to apply the methodology to a set of proprietary hardware devices being developed 
inhouse for use in a number of aeronautics and space applications. NASA sponsored a Boeing 
engineer to work with the Processor Interface Unit (PIU) design team to formally specify 
and verify the device. Although the NASA contract with Boeing will end in FY93, Boeing 
has already capitalized on the NASA program and has started their own IR&D effort to 
continue applying formal methods to the set of devices. 

The cooperative research effort with Boeing has helped NASA Langley to assess the 
maturity of formed methods technology with respect to state-of-the-practice digital flight- 
control systems. First, Boeing was tasked to analyze the suitability of the VIPER chip for 
application to digital flight controls and to assess the design/verification methodology used 
on the VIPER[54] 4 . The generic-interpreter and horizontal-integration theories developed at 
U. C. Davis provide models to guide the specification and verification of hardware devices. 
Application of formal methods to the PIU has demonstrated that formal methods can be 
practically applied to the digital hardware devices being developed by Boeing today and has 
given NASA insight on how to make the process more cost effective. 

Work is also progressing on a methodology for formal requirements analysis for aircraft 
systems[58, 59]. This work, being performed under a subcontract to California Polytechnic 
State University, includes development of a Wide-Spectrum Requirements Specification Lan- 
guage (WSRSL) and prototype tools to support the language. A set of requirements for an 
Advanced Subsonic Civil Transport (ASCT) developed by a Boeing engineer under previous 
NASA funding is being rewritten in WSRSL to demonstrate the use of the language and 
toolset. Since WSRSL is a formal language, the specification can be formally analyzed for 
syntactic correctness, completeness, and consistency. NASA Langley is currently evaluat- 
ing WSRSL as a candidate requirements specification tool for the fly-by-light/ power- by-wire 
project. Future plans include possible development of an automatic translator to Ehdm (SRI 
International’s theorem prover) to facilitate verification of functional correctness as well. 

4 NASA Langley has just completed a 3 year Memorandum of Understanding (MOU) with the U.K. 
Royal Signals and Radar Establishment (RSRE) in formal methods. The MOU focused on the VIPER 
microprocessor and the verification methodology used in its development. Computational Logic Inc. and 
Langley inhouse researchers also performed assessments of the VIPER project[55, 56, 57]. 
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NASA FM Repository 

An anonymous FTP account has been set up at Langley to make the research results readily 
available. Formal specifications, research papers, and other useful information will be stored 
in machine-readable form. To access this repository, one must issue the following command: 
“ftp airl6.larc.nasa.gov”. One then supplies “anonymous” as the user name and his FTP 
address as the password. 

Summary 

Although the NASA program covers a wide-spectrum oT theoretical and practical problem 
domains, it is strongly focused on the goal of designing a fault- tolerant reliable computing 
base which can support real-time control applications. Much progress has already been made 
in applying formal methods to critical subsystems s uch as clock sync hronization, Byzantine 
agreement, voting, etc. The challenge ahead is to integrate all of these activities to accom- 
plish a complete verification of the total RCP system and to continue the transfer of this 
technology to the aerospace industry. 
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LANGLEY FAULT-TOLERANT DIGITAL SYSTEMS 
HISTORICAL PERSPECTIVE 


CA. 1972 ARCS 

CARSRA 

SIFT 

FTMP 

CARE III 

LIC SOFTWARE 

IAPSA 

SURE/ASSIST 
CA. 1992 AIPS 


F-T SYSTEM DESIGN 
RELIABILITY ANALYSIS 
F-T COMPUTER 
F-T COMPUTER 
RELIABILITY 
S/W ERROR ANALYSIS 
F-T DFCS DESIGN 
RELIABILITY ANALYSIS 
DISTRIBUTED F-T SYSTEM 


ULTRARELIABLE DIGITAL AVIONICS 


CONTROL SYSTEMS BECOMING THE PRACTICAL EQUIVALENT OF PRIMARY 
STRUCTURE 

• U.S. FAR 1309-1 Requires P(fall)<10 for statistical compliance 
. Reliability can't be estimated to this level 

. Experienced engineering and operational judgement used for compliance 


FAULT-TOLERANT DIGITAL SYSTEMS ARE NECESSARY FOR PRACTICAL 
REALIZATION OF ADVANCED CONTROL 

• Analog functionality insufficient for advanced control 

• Analog too high in size, weight, power 

• Digital system components not adequately reliable - use redundancy to 
increase reliability 
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FORMAL METHODS FOR 
FLIGHT-CRITICAL SYSTEMS 


• The only scientifically satisfactory approach to aspects of the 
digital validation process is through reasoning 


• Formal methods may become important sooner than is 
commonly supposed in the aerospace community 


• SVMB has put an emphasis on formal methods 

• Industry/FAA focus Is essential feature of our formal methods 

work 


j 
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( 10 9 hours = 114,000 years) 
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tions — A calculus for analyzing and predicting the behavior of 

systems — formal verification 

• Computers can provide speed and accuracy for the calcula- 
tions 
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• prove that the design will satisfy the requirements, given 
the assumptions 

• protte that a more detailed design implements a more ab- 
stract one 


Mathematics of Formal Methods 
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ELSE X i« AfT] AND (i < Y < N)\ 
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Specifying Adding/Deleting an Entry 
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What Makes a Technique a “Formal Method?” Expressibility Vs. Proving Efficiency 
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Tutorial 

Design Specification Techniques 

Ben DiVito 

ViGYAN 


43 



« 

£ 

0 

o 


a 

1 

o 

o 

a 

o 


! 

« 

£ 

l 


l 


1 ? *5 


a 

h 

i 

i 


« 

© 

*3 

cp 

a 

P 


§ 


0 ) 

3 

ai 


a 

I 

a> 

a 

O 


x 

-h» 

*s 

i 

i 


u 

i 

a 

p 

.2 

1 

<E 


a 

.2 

1 

<c 

•E 

% 


0 

.2 

•M 

s 

«5 


8 

o 

O 


& 

V 

8 


I 

*8 

<P 

1 

a 


I 


cb 



3 

> 

5 

hi 

e 

£ 



& 

07 
V 

8 


8 

.2 

%-* 

8 

U 

«P 

I 

U 5 

1 


£ 



44 



45 




1 


i * < 

H " " 


I f 

“ o. .S 

l s : 


.} % ! 
g 2 
s *S .& 

•S © -M 

® g 3 

s 2 E 

« U M 

c c g 

§ -3 ’3 


w 0 } 

’ S 2 
ri _ 


A A J 

i 6 ? 


S *. .B 

s * s ■* *j 

U J 4) I A 

g 3 c • | 

3 I 5 3 I 

o fc «a fr* e 


U 1"., 

3 5-25 


1 f I 
f h 
I 

.1 a 2 

S II 


1 J 

x © ' 

® > < 

fe J , 


I ? 

I I 
3 1 1 
* ® « 


46 


op«ratiomp©c( P y 5, t £>, J 

where P, P„ denote the parameters at the operation interface (additional 
conventions are needed for return values, exceptions, etc.) 
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formalism is no long costj-effective, but: the high level specifications and , Hierarchical specification techniques outline 

proofs are still valuable 



Tutorial 

Code Verification Techniques 


C. Michael Holloway 

System Validation Methods Branch 
NASA Langley Research Center 
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Tutorial on Code Verification Techniques Outline 
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{Final assertion under variable 
substitutions due to assignments} 



Software Example: Linear Search 

Method of Proof (continued) English Specification 


03 


E JO o 


| S 
s a 


t a e •• 

m £ £ oc 

i << ■* w 

_) I wo 

is 3E 

£ B H 

O i S 

K ** W 


- . u 

0> 0) 


0) o 

h U- 


r o 5 
h 2 € 


51 




52 



CO 

to 

<u 

u 

o 

Ql 

O) 


U> 

c 

N 

c 

fU 

JC 

u 

q; 

2 


ro 

> 

> 

0 
T3 

1 

cy 

s 

a 

3 > 

2 
3 

o> 

c 

2 

c 

o 

ro 

u 

? 

9 

2 

3 

ro 

T3 

ro 

w 

& 

c 

3 

U a> 

5 2 

5 ro 


? 

> 

O 

1 ? 

I I 

ro o 

C g 

n s 


i 

9 

3 

a 


£ 


0 > 

3 


■o 

a 

-a 

L» 

<y 

> 

C 

0 

u 

E 

Q) 

3 

o 

& 


T 3 

a 


3 

TO 

>v 

3 


a 


o> 

c 


u 

U 

c 

5 

4-* 

0 

8 

C 

4a 

c 

0 

w 

o 

<y 

E 

ft 

$ 

w 

£ 

« 

o 

a 

< 

& 

U 

o 

& 

§ 

1 

i 

l 


£ 

h 


to 

cd 

> 

O 

v. 

Q. 

E 

CD 

l- 

O 

0 ) 


03 

c 

05 

-C 

u 

0 ) 

2 


01 

V 

o 


o 

E 

'O 

3 

£ 


o 

o 

o 

3 


a 

s 

E 

<y 

T 3 

> 

o 


§ 


£ 

h 


ro 

> 

o 


-3 

U 


£ 

o 

w 

o 


c ^ 

w w 

= « 

ID — 


C 

ro 


§ ? 


c 

o 

-M 

3 

fl 3 

w 

0 

01 


S JS £ 


<y 

c 

o 

£ 

cy 

■a 

> 

o 


o 

o 

* 

O* 

c 

*C 

o 

o 


o 

o 

fc 

□> 

c 

> 

fTJ 

a 

<y 

w. 

*D 

C 

ro 

cn 


0 

w 

to 

1 



a 

OJ 




♦a 




1/1 



> 

s 



*a 

w 



a 

tl 



c 




3 

l 


o 

5 

«a 

U 

C 


o 


3 



» 



£L 

8 

c 

Q) 

£ 

4 a 


CD 

4 a 

y 



-C 


| 

a? 

4 a 

c 

8 

w 

‘*5 

ro 

c 

O 

3 

c 

o 

P 

cn 

€ 

m 

u 

j, 

a 

cy 

*■» 


CD 

-M 

o 

z 


cy 2 
2 > 


c 

O 

w 

a 

<y 

£ 


ro 


£ 8 

W c 

S! 
$ - 
o z 

o IS 

^ i** 

^3 #3 

4a >■ 

O T3 


c ** 

§ 0 > = 

£ <y 

£ ~ 3 

«a 75 

§ 8 5 

| S t3 

■c _ a; 


£ 

y 

£ 

$ 


cy 

<y 3 

% g 
2 E 

n j~ 
Q vy 
cy cy 

01 *a 


* 2 

a 

c w 

o c 

*£ cy 

m w 

a 


p fc 
C ■" 


o 

w 

C 

c 

o 

w 

c 

E 

w 

<y 

4 -* 

u> 

c 


£ 

t/> 


E 

ro 

I 

& 


1 ^ 

cy 

ai 

c 

> 

4 a 

g 

cy 

a 

E 

2 8 

*£ 

ro 


ro 

X 

c > 

w 


cy 

4 > m 
> 2 

4 a 

01 

c 

o 

£ 

01 

<y 

f W 

3 

cy 

£ 

4 a 

cj Q. 

o 

a 

5 

1 JC 

Q 

cy 

w 

U- 

• 

• 


• 


£ 

a 


£ 

E 


cn 

to 

a> 

u 

o 


CD 

-C 

-M 

cn 

c 

‘n 

*E 

05 

sz 

u 

05 

2 


a 

£ 

o 

6 

■o 

ft 


c 

ro 

*■» 

o 

a 

£ 


2 

'<0 

I 

X 

<y 

s 

5 

3 

0 
£ 

01 


01 

E 

2 

£ 

O 

& 


0> ol 
U “ 


O 3 


w IS 


c 

2 O 

5» IS 

C N 
2 % 
c E 

.2 & 

4a £ 

ro _ 

S 3 

a o 
to W 

I 


c 

*3 


■o 

£ 


U 


O *■= 


2 £ 


8 & 

^ s 

0 > 

CT O 

2 i 

1 E 

J E 

> g 

8 3 
& .g 
x c 
O 

cy -3 
k ^ 
0 O 

2 E 


53 


Accumulating deductive knowledge 



Mechanical Theorem Provers (continue) Concluding Remarks 
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Formal Methods Chapter 
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The chapter is o Abstract data type and its implementation (stack) 

o A very detailed exposition of issues in application of formal ° Design-level modelization (library) 

methods to critical systems 0 Algorithm (Oral Messages algorithm for Interactive 

o Addressed to an audience wider than certifiers (developers, Consistency) 

managers, engineers) 
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be done formally, but are different from conventional formal • Early lifecycle 

methods p rQ; that’s where the serious errors are; that's where the 

concern is; few other rigorous techniques available 
Con: front-loads development time and cost 



Validation of Specifications 
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allow it to be documented 



Formal Methods and Tools 
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Survey of State-of— Practice 
Formal Methods in Industry 

Dan Craigan 

ORA Canada 
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Overview of Presentation 


Survey of State-of-Practice: 
Formal Methods in Industry 


• Purpose, sponsors and researchers. 


• Method for conducting survey. 


Dan Craigen 
ORA Canada 

danOora.on.ca 

NASA Langley, Virginia 
11 August 1992 


• Cases: An overview. 

• Example case: TCAS. 

• Example feature: Tools. 


• Observations. 


i 
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Purpose, sponsors and researchers 


• To provide an authoritative record on the prac- 
tical experience to date. Purpose, sponsors and researchers 


• To better inform industry and government 
bodies developing standards and regulations. 


• To provide pointers to future research and 
technology transfer needs. 

• Value added: Case studies and analysis. 


• AECB, NIST, NRL. 

• Dan Craigen, Susan Gerhart, Ted Ralston. 
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Method for Conducting Survey 


Method for Conducting Survey Process 

Initial questionnaire. 

Literature review. 

Structured interviews (Second questionnaire). 
Raw notes, case report, review. 

Review committee. 


Questionnaires 

• Initial questionnaire and structured interview 

• Organizational context. 

• Project content and history. 

• Application goals. 

• Formal methods factors. 

• Formal methods and tool usage. 

• Results. 
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Method for Conducting Survey 
Analytic framework 

Product features. 

Process features. 

FM R&D summary. 


Method for Conducting Survey 
Product Features 

• Client satisfaction. 

• Cost. 

• impact of product. 

• Quality. 


Key events and timing. 


• Time-to-market. 



Method for Conducting Survey 
Process Features 

• Cost. 

• Impact of process. 

• Pedagogical. 

• Tools. 
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Method for Conducting Survey 
FM R&D Summary 

• Methods: specification; design and implemen- 
tation; validation and verification, [uses] 

• Tools: language processors; automated rea- 
soning; other tools, [tools] 

• Recommendations to FM community, [needs] 


Method for Conducting Survey 
Process Features 

• Design. 

• Developing reusable components. 

• Using existing reusable components. 

• Maintainability. 

• Requirements capture. 

• V&V. 

10 


Method for Conducting Survey 
Key Events and Timing 

• Starter. 

• Booster. 

• Status. 
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cases: An overview 


Cases: An Overview 

• CASE 

- SSADM toolset; commercial; /. 

- 340pgs 2/English; 550 schemas; 
37KLOC obj. C; 16.5 linos/day 

• CICS 

- Transaction processing; commercial; 2; 
PS/2 tools. 

- 268KLOC new/modified code; 
50KLOC traced to 2 specs; 

9% improvement in cost; 

60% reduction in APARS. 
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• Clean room 

- COBOL structuring and Attitude control; 
commercial and government; 
functional specs, and testing. [Method] 

- 80KLOC; (20KLOC reused; 18KLOC 
changed; 34KLOC new) 

- 34 lines/day; error rate of 3.4/KLOC 
(l/20th industry average). 

• Darlington 

- Shutdown system; regulatory; A-7 style and 
program function tables. 

- SDS1 : 1362LOC Fortran; 1185LOC As- 

sembler 

SDS2: 13KLOC Pascal (??). 

14 


Cases: An Overview 

• LaCoS 

- Engine management and a distributed con- 
troller; ESPRIT and commercial; 

Raise [Method]. 

• Multinet Gateway 

- Network security; NCSC; GVE, etc. 

— lOpgs math; 80pgs Gypsy; 6KLOC OS. 

• SACEM 

— Automatic train protection system; safety 
critical and RER; B, Hoare triples; B tool. 

— 9KLOC verified code; Total of 315,000 per- 
son hours. 


Cases: An Overview 

• TBACS 

— Smartcard security application; security; FDM 

- 300 lines of FDM; 2500lines of C. 

• Tektronix (oscilloscope) 

- Reusable software architecture; commercial; 
Z; Fuzz. 

- 200KLOCof code; I 5 pgs of Z specs (twice). 

• TCAS 

- CAS Logic and surveillance; regulatory; state 
charts with DNF tables. 

- 7KLOC of pseudocode; specs about the 
same size. 
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Cases: An Overview 


Example case: TCAS 


• Transputer 

- T-800 FPU, VCP; commercial; Z, HOL, 
mathematics. 

- FPU: lOOpgsZ; 4KLOC Occam; VCP about 
10 6 states. 

• HP-AIB 

- real-time data-base; commercial; HP-SL. 

- 55pgs HP-SL; 1290 lines of spec and design; 
4390 lines of code. 
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TCAS 

• Players: RTCA Inc. (SC 147), FAA, UC Irvine, 
Mitre, Lincoln Labs. 

• Interview profile: Leveson, Nivert, Lubkowski, 
White. 

• CAS Logic and surveillance system. 

• 7 KLOC pseudocode. 

• 700 pages English description. [Terminated] 


• Traffic Alert and Collision Avoidance System. 

• TCAS I, II. III. 

• Congressional fiat (1993). 

• Grand Canyon collision. 

• Time span from early 80s. Leveson in June 
1990. 

18 

TCAS 

• FM for safety analysis, [model checking and 
automated deduction] 

• Statecharts. 

• DNF tables for conditions. 

• Iteration on notation. 

• Strong support from SC 147 and industry. 


• Loss of intellectual control. 


• Currently at IV&V [15 pys over 8 months]. 
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Product features 


Client satisfaction 

\ 

Cost 

n/a 

Impact of product 

n/a 

Quality 

n/a 

Time to market 

n/a 


General process features 


Cost 

n/a 

Impact of process 

+ 

Pedagogical 

+ 

Tools 

n/a 


T CAS (Key Events) 

• Starter: FAA seeking better rqts. for deployed 
and troublesome system; Leveson looking for 
demo project. 

• Booster: SC 147 willing to accept new ap- 
proach; Readable notation. 


Specific process features 


Design + 

Developing r. comp, n/n 

Reusing r. comp. n/a 

Maintainability n/a 

Reqts. capture + 

V&V n/a 


• Status: CAS Logic formalism and pseudocode 
in IVV. Surveillance logic current. 
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T CAS (R&D) 


T CAS (R&D) 

• Uses: Mod. to Statecharts 

- Concurrency as parallel state machines. 

— Tabular notation. 

— Specs, reviewable and IV&V. 

- CAS Logic from pseudocode and English. 


• Tools: LaTeX. 

• Needs: 

— Safety analysis tool. 

- Automated deduction and model checking. 

- Well-formedness checker. 

— Foundational issues. 

• Conclusions: successful transition and applica- 
tion. 
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Tools (Usage) 


Tools (Usage) 


• CASE (SSADM): Prototype Z parser and type- 
checker. 

• CICS: PS/2 based toolsuite w/ editor, type- 
checker, semantic analyser (Z). 

• Cleanroom: Editors, waste paper basket. 


• SACEM: B. 

• TBACS: FDM, scrolling, pencil and paper X- 
ref. 

• Tektronix: Fuzz editor, typechecker and pretty 
printer. 


• Darlington: Microsoft Excel. 

• LaCoS: Raise toolset. 

• Multinet: GVE, Extractor. 


• T CAS: LaTeX. 

• Transputer: Occam transformation system, in- 
house refinement checker. 

• HP: HP-SL syntax checker. 
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Tools (Needs) 


• CASE (SSADM): schema expander, enhanced 
editor, browsing and X-ref. Tools (Needs) 


• CICS: schema expander, semantic analyzer (for 
all Z), configuration management. 

• Cleanroom: Extracting and tracking verifica- 
tion events. 


• Multinet: Better automated deduction, improve- 
ments for industrial scale, soundness, better 
notation. 

• SACEM: Better integration with other V&V. 


• Darlington: automated deduction, POG, book- • TBACS: Better interface; large expressions and 

keeping. many proof steps. 

• LaCoS: Experience with automated reasoning 
tools. 
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Tools (Analysis) 


Tools (Needs) 

Tektronix: schema expander, refinement proof 
tool, pre-condition calculator. 

TCAS: safety analysis tool, automated deduc- 
tion, language checker, soundness. 

Transputer: refinement checker for large state 
spaces. 

HP; Language checker and better notation (not 
ambitious!). 


Did the formal methods tools help or 
hinder the development of the product? 
Were the tools reliable? 

CA Cl CL DA LA MG SA TB TE TC TR HP 

+ 0 n/a 0 0 + + -n/a + 0 

• Not a large role (lack of tool support). 

• Problems due to newness and primitiveness. 

• Need for language checkers, bookkeeping. 

• Don't be too ambitious. 


• Automated deduction in critical applications. 
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Observations 

Features: 


Observations 
Formal methods 


Definite positive influence on design, require- 
ments, V&V, and pedagogical. 


• Methods: state machine; lst-order predicate 
calculus; reviewability; complete refinement. 


Positive influence on 'impact on process' and 
quality. 


• Tools: Language processors; bookkeeping; 
browsing; x-ref. 


Neutral on cost. 


• Needs: Integration with other V&V; concur- 
rency and timing; lower barriers of entry. 



Availability of Report 


• Availability within 2-3 months. 


• Send email to danQora.on.ca, or mail to: 


Dan Craigen 
ORA Canada 

265 Carling Avenue, Suite 506 
Ottawa, Ontario K1S 2E1 
Canada 
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Formal Modelisation 

Susan Gerhart 

National Science Foundation 


71 



Modelisation 

Sure you’ve proved it correct, 
but what does the system REALLY do? 

Susan L. Gerhart 
sgerhart@nsf.gov 


Subjects: 

The SAC EM Case 

{continued from Dan Craigen’s presentation)-- 
how FM was embedded in an industrial process 

Issues of "modelisation" 


Software Engineering for a 
"Formal Methodist" 


Requirements Mathematical model of the system that allows 

property exploration 

Specification "the system' expressed in mathematical 

notations 

Design Operation decompositions and data 

refinements 

Implementation Code * Assertions ♦ Assumptions 

Validation Spec Execution or prools of properties 

Verification Identification and discharge ol conectnoss 

obligations 

Documentation Prose and diagrams that go with lha 

mathematical notation 

Ule Cyde Get the specification right and agreed upon 


Background Point of View 


SACEM: 

Train control for the Paris Metro 


The Job: 


Shorten the train intervals to 2 minutes to avoid a new Paris line 

and 

Convince the Parts Transit Authority the system was safe 
lurid up an international business in safe train control systems 


Who: 

GEC Alsihom Matr a'CSE E ♦ Pans Transit Authority 


The Process: 


ig70s Decided had to go with new software and 

hardware 

Explored fault lolerance, discovered proof of correctness techniques, 
did safety studies 

1960$ built prototypes 

verified code one way, 

found new way to specify and verify. 

worked with authorities to demonstrate safety, 

brought on-line - 


i990s demonstrated capability on other systems, 

commercializing tools used in the process 


The Results: 

Verification was demonstrated as an addition to simulation, without 
excess cost and with significant added assurance 

Specification and mode fi sal ion matured and an industrial process 
was defined 


SACEM System 



Tram ’A" Train "B’ 


Challenges : 

* Different kinds of Voffing stock' to detect, 
some protected and some not 

• Variations in track-beacon technology, tunnels & rivers. 

• Getting the train "home' when it's system does fail 

* Encoded single processor (rather than complex synchronized 
multi processor) -- as fail safe as possible 
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SACEM Background 


SACEM lessons for Formal Methods 

An industrial process has been put in place that is evolving 
toward 

Understood and documented 
Measured and predictable 
Regarded as cost eltoctrve 
Tool supported 

Probably comparable to MoO 0055 

Many techniques can play together, 

{although not in concert yet) 

SADT lor graphical system decomposition and analysis 
FSM (Graphcel) simulator 
Hazard analysis 

Operational scenarios (600 ol them) 

Real lime design simulation 
Prototyped system 

Code verification & specification refinement 

Technology Transfer problems could be overcome 

A manager understood and stuck with it 

Tlte customer was educated (and did their own thing) 

Pioving could be crodibly compromised 
Modulisalion wil Iwlp synthesize their rosulls 


maintained spec outermost guided by design 
vvw refined down vvw 
unlit too detailed 


until too sophisticated 
^"abstracted up **** t „ 

maintained code innermost loffowing ho ad or s. not body 


Total: 315,000 hours (V&V = 1.5 x Development) 

formal prool 32 4% 

module lusting 20 I % 

functional testing 25 9% 

re - specification 2 1 6% 





Tran Track 1 

Number of procedures proven formally 

1 1 1 

21 

Number erf procedures covered in somi global lusts 

120 

33 

Number ol procedures tested semi globally 

79 

67 

Number erf procedures tasted globally 

J80 ^ 

167 


Moderation 


The process of getting all the stakeholders to understand 
and agree that tne working description conveys the 
intended system. Subsumes requirements analysis, 
mathematical modeling, etc. 


In SACEM, 


Tra ck *, trains, beacon*, encoded mproc. 


Safely principles 
The description notation itself 
The process ol using the description 
Problems encountered with modelisation in SACEM: 

laborious code description disconnected from The theorem' 
Concurrency difficult to express in lop level nxxtal 

Different representations, different analyses were used for 
assurance (tee tools Usl) 


Many kind* ol syslem views: certifier. railway switching, 
microprocessor developer, formal verifier 

Refinements were OK, but there was a code gap (now 
generated) 


Carry-over from Requirements 
Analysis 

Given a language and tools, how do you express the 
requirements and model the system? 

Translate English and diagrams to sets, logic, etc. 
and translate back and forth, but 

how do you read and clwck these 7 
what diagrammatic techniques match FMs? 

CORE. JSD, GIST, SADT etc provide; 

standard syslem representations 
ways to get ditlorent viewpoints 
domain modeling techniques 

Software process modeling offers: 

Guidelines lor use 

Basis for data collection and eventual metrics 
Opportunities tar mtugralion, o g with touting 
Basic appoarance ol manageability 
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Modelisation Process 

Identification 

Entities 

Constraints among entities 
Operations and their parameters 
Representation 

Entities become values of a type 

Types must be defined to construct, modify and examine their 
contents 

Representation issues are considered, e g. ordenng, duplication, 
primitive types, attributes 

Additional properties of the data types from requirements 

Operations defined with their parameters 

Restrictions are expressed as pre conditions 

Us effects are defined in terms of parameter values before and 
after execution 

System invariants a/e formulated from properties that the system 
is required or expected to have 

Invariants are proved by induction: 

(And a collection of definitions is built up) 


The limitations of the model are identified, e g 
Omitted operations or data deiads 
implicit definitions 

Assumptions about the operating environment 
(system and users] 

Degree of concurrency expressed 

Reliability of communication media 

Performance, resource, and security requirements lhat must bo 
met by the implementation 

A plan for using the mode) is developed, e.g. 

identifying the riskiest or least u/iderstood part lor further 
analysis or refinement 

iteration toward more extensive models 

Formal proof of properties Of the model 

Validation, e g. by 

Prototyping from the model 

Reviews, inspections, and other peer analyses 

Animation of the mode* 

Scenarios to stimulate response from customers 


Summary 


SACEM Case 

“Complete" application of formal methods 

Shows us potential for integration of FM into broader 
system engineering 

Displays interaction of problem domain and formalization 
Modelisation 

Process aspect to add to FMs^ as languages & tools 

Integration of standard computer science with application 
domains 

Challenge to FM Vendors: 
write down your process model 
and 

show how moderation is performed 
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Formal Methods Technology Insertion 

Into FTPP 

Rick Harper 

Charles Stark Draper Labs 
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Formal Methods Technology 
Insertion 
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Formal Methods Technology 
Insertion into the FTPP 

Objective: 

Use formal specific ation and verification of 
critical FTPP hardware and software 
components to reduce the Incidence of 
common-mode failures due to specification 
and implementation errors 

Formal methods do not help avoid many sources 
of common-mode failures 

environmentally-induced faults: EMI, 
radiation, heat, water, corrosives, sand (!) 

Formal methods are not the only solution to 
common-mode fault avoidance, removal, and 
tolerance " 


Fault Tolerant Parallel Processor 
(FTPP) 

High-throughput high-reliabillty/avaiiabiiity 
computer for hard real-time applications 

Uses many Processing Elements {PEs} in 
parallel for high throughput 

Uses redundant PEs lor high reliability 

Tolerates arbitrary failure manifestations 
("Byzantine Resilient”) 

Designed primarily to tolerate uncorrelaled 
hardware faults 

Programmed in Ada 


Mature components, standards compliance, 
design automation tools, ruthless persecution 
of complexity, conservative design practices, 
simulation, testing, various CMF 
detection, 'recovery mechanisms 


NASA Fwrtt' MetTods Worts! io^i ~ ’Ii'ij 1993 J 


¥';SA>crm*r Wcrknc p 11-fT£5gu*« 1992 4 
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Current FTPP Applications 


Fault Tolerant Parallel Processor 
(FTPP) 

Can trade throughput (parallelism) lor 
reliability (redundancy) In real-time 

Can be dynamically reconfigured to optimize 
mission reliability and availability 

Supports mixed simplex, triplex, and 
quadruplex redundancy 

Allows heterogeneous processing resources 
Parallelism * transparent to programmer 
Fault tolerance - transparent to programmer 


"The Army Fault Tolerant Architecture (AFTA) 
Program" 

Funded by: Army Electronics Integration 
Directorate / NASA 

Application: Helicopter TF/TA/NOE/FCS 

"Heterogeneous FTPP" 

Funded by: Army Strategic Defense 
Command 

Application: Battle Management 


"Fault Tolerant IMU Processor" 

Funded by: a commercial aerospace company 
Application: IMU processing 


NASA For mi Mothodi Workshop 1*1*13 Augu*H9$2 


NASA Formal Methods Workshop 11-13 Auguil 1 992 


Cluster 3 (C3) FTP P 


FTPP C3 Architecture 


Third-generation FTPP 

Processing Elements 

Support 3 to 40 PEs per cluster 

680x0s, 80960s, MIPS R3000S, 1860s, or 
DSP32C signal processors 

Network Elements 

100 Mbit/sec fiber optic interchannel links 

facilitate fault containment and physical 
dispersion 

Standard bus Interface to Processing 
Elements 

Software 

XDAdaTM-based operating system with 
CSDL extensions 



NASA Formal Moihodo Workshop 11-13 Augutt i99i T 


NASA Formal Molhoda Workshop n-i3Augu«1 1992 


77 



Layered View of FTPP 


Components of FTPP Suitable for 
Formal Methods Insertion 



Processing Element 
Network Element 
FCR Backplane Bus 
VG Synchronization Software 
Task Scheduling Software 
Inter-VG Communication Software 
FDIR Software 


ftASA Formal M«»hods Woikshop 1 1-13 August 1992 F 


NASA Form*! Methods Workshop TTTij August 1W2 10 


Processing Element 

Formally specified / verified microprocessor can 
be used in FTPP 

Processors interface to FTPP over standard bus 
(e.g., VMEbus) 

Not all processors In FTPP need be formally?". 
verified 

Could use small number of formally verified 
processors to form quad or triplex Byzantine 
resilient core VG which runs a simple verified 
kernel — 

Core VG responsible for monftorrng other 
VGs (Including CMFs) and resetting offenders 
using vot«d_resat capability of NE 

Throughput of core VG not an Issue. ..can get 
desired throughput adding higher-throughput 
VGs in a heterogeneous parallel processing 
configuration 

All VGs communicate using BRVC 


NASA j- nrr> i Meinodi W S**l3 ugusl 1592~ |Y 


Network Element 

Executes performance-critical Byzantine 
resilience algorithms -= 

Provides BRVC abstraction 

Generates vote, FTC, link, and other syndromes 

AH components execute specifiable and verifiable 
algorithms ^ — -- 

Bus interface 

Voter / syndrome accumulator 

FTC 

Global Controller 
Scoreboard 

Substantial body of related work from formal 
methods community Is relevant to these functions 


NASA ForinS WorkiFop" n-i3”Augwsi 1M2 ” 12 
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FCR Backplane Bus 

Backplane bus used for PE-NE communlcalion 

NE partitioned into bus-dependent and bus- 
independent sections 

Can retrofit NE to formally specifiedA/erified 
backplane bus by modifying bus-dependent 
section 

Formal model of backplane bus needed 

Backplanes are a common component ol 
many systems 

A formally specified and verified backplane 
could find wide use in critical systems 

Powerful building block for ultrareliable systems: 

Formally specified and verified processor 
resident on formally specified and verified 
backplane bus card 


NASA Formal Methods Workshop ' 1 1-1 3 August 1 992 


Byzantine Resilient Virtual Circuit 
Inter-VG Communication Abstraction 


tJIWffi'i ^ ,kFi»rii j 

•nuikJtO 

SoWiaVUt ) I U-rwui** VCi, 



Mai sagas aant by non-faulty mam bars ol a aourca VG ara 
correctly delivered to lha non-faulty members of recipients 

Non-faulty members ol recipient VGa racaiva massages In the 
order aant by the non-laulty members of lha source VG 

Non-faulty mambars ol recipient VGs racaiva massage* in 
Klantlcal order 

The absolute lima* of arrival of corresponding messages at the 
members ol roclplant VGa dllfer by a known upper bound S 

The time between a valid massage transmission request and 
massage delivery possesses a known upper bound t 

The BRVC pbstractlon is supported by the NEs 


m* ifcrhiarsrciYiiHJr 
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VG Synchronization 

VGs are synchronized upon periodic timer 
interrupts (e.g., at 100 Hz) 

Timer Interrupts occur within a bounded skew on 
all members of VG 


Upon timer interrupt a VG performs a 
synchronizing act (i.e., message passing using 
BRVC) 


Send message to self 
Await reception 


J MG 
Mcnibci 


Mti » 

rnibcf F m. 

o L. — 


vH 

wnJ 

"A ‘ Lid ~ 


» Kikl rrv»ic 


•7 -T-: 7 - T' 


NASA Formal U#ih odVWoikih op " iT-lTAugusMMJ ' ff 


79 








Inter-VG Communication 


Rate Group Scheduler 

FTPP C3 umi limer-based preemptive rale group 
scheduler 

Variant of rafe-monotonic scheduling optimized 
for Iterative task auitaa having harmonic Itaratton 

rates 


Tasks Interact only at frame boundaries 


z.t-m 



FTPP OS schedules appropriate tasks at each 
frame boundary 


Fnm Boundary 

ComptolPd HO# 

Started RG« 

7-e 

4. 3, 2,1 

4. 3, 2, 1 

D>1 

4 

4 

1-2 

4,3 

4,3 

23 

4 

4 

>4 

4, 3,2 

4. 3,2 

4-5 

4 

4 

5-5 

4,3 

4,3 

S-7 

4 

4 


ms* Fef*MTlie*otfi tfwiiihpp ' IM3 Auputl tW3 "" if 


FTPP tasks communicate using message passing 

queue jaesssge OS call pieces message onto 
outgoing queue to NE 

FTPP 03 determines destination VG from task-to- 
VG mapping table 

OS transmits message queue to destination VG 
using BRVC 

Recipient VG’s OS reade message bom NE and 
places Into destination task input message queue 

ret rlev«_Ms sage OS call accesses appropriate 
task input queue and delivers message to task 


Alt and Inti r-Y G communication 

aaMtiteaA ia iodggflgrfgat oL YQ rrtuntenw 
Sue! " 
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FDIR 

FOIR partitioned for valldatability 

Local FDIR runs on each VG 

System FDIR runt on designated VG (e.g., 
formally verified VG) 

Algorithm: 

Local FDIR 

Executes self tests 

Scrubs RAM (i ndependent of 
characteristics of applicat ion tas k suite) 

Periodically transmits seif test results to 
system FDIR vie “presence message" 

System FDIR 

Examines contents and syndromes of 
presence messages to diagnose senders 

Failure to receive presence message within 
bounded time implies common-mode failure 
of sender 


Fault Recovery ~ 

Many recovery policies possible in FTPP 

Reduce redundancy level 

Reintegrate faulted component 

Replace faulted component with spare 

System FDIR determines appropriate recovery 
action and either - - - - — 

transmits recovery commands to local FDI for 
focalized recovery or 

performs global system-level recovery 

Must show that system FDIR determines correct 
recovery action as a function of diagnosed 
comp onent 

Musi show that focal or system FDIR correctly 
carries out specified recovery 


H£5A?e«mai ft** ed* Work** up - TT»5 August i9W if 
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Heterogeneous Kernels on FTPP 

Nol all karnels In FTPP need ba Identical as 
long as they can communicate using BRVC 

FTPP can host rata group scheduler on 
production VQs and small formally verified 
kernel on formally verified VGs 

Message gaialng thr°u9 h BRVC subsumes 
synchronization so Ihe f ormally yeiitifid 
kernel would not explicitl y perform 
synchronization of redundant sites 

The formally verified VG would execute the 
system FDIR function 


'NASA Formal Methods Workshop 1 1 - \ 3 AuguM 1 M2 


Conclusions from Scoreboard 
Specification and Verification 

Formalization of Scoreboard requirements 
uncovered several specification omissions and 
ambiguities 

Collaboration would have been closer and impact 
on design greater If Draper had been specifically 
lunded to participate 

Incremental cost on a $2.4M brassboard 
development program Is small 

Benefit to cost ratio is very high during the 
conceptual study and detailed design phases 




Work in Progress: Scoreboard 
Specification and Verification 

Currently collaborating with ORA to formally 
specify Scoreboard 

Scoreboard Is a critical component of FTPP 
Comprises approximately 50% of NE circuitry 
Enforces BRVC abstraction 
Business Modal: 

FM experts working closely with engineering 
staff having little exposure to formal methods 

Separate funding (Draper not specifically 
funded to collaborate) 

Scoreboard described in VHDL and constructed 
using automated synthesis (Synopsys) 

VHDL used as common language between Draper 
and ORA 


TiASA Foriral Methods Workihop 1 M3 Ai»gu*f » 9M 


Work Planned and Critical Needs _ 

Work Planned 

Components similar to remainder of NE (i.e. t FTC, 
voter) have been formally specified/verified 

Would like to adapt this work to FTPP 

Actively seeking FV processor to design into 
FTPP 

Planning to develop selected subset of RCP 
software for FTPP 

Critical Nes da 

Viable processor 

Formal subset of VHDL, with nonempty 
Intersection of synthesizeabie and formal subsets 

Continued formalization of FTPP NE 

Formal model for FCR backplane bus 

Formalization of critical OS functionality 

Business model for formal methods Insertion 


NASA fwmS WiSodi Wwkthop ~ u-i3 Auguii mf 
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Formal Methods at 
IBM Federal Systems 


David Hamilton 

IBM Federal Systems 
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Introduction and Purpose 


Harlan Mills and SEW 


e To cover 

1. Some IBM involvement in Formal Methods (FM) 
projects 

2. A perspective on difficulties of technology transfer 
(beyond a single project) 


e Purpose is not to 

- sell the "IBM approach" 

- argue against feasibility of FM 


e Purpose is to 

- learn from other FM technology transfer projects 

- suggest some possible future directions 


• Mills led massive software engineering education 
program 

— Software Engineering Workshop was cornerstone 
| 2 week course 

| Taught to ail programmers 
| Required to pass final exam 

• SEW centered on mathematically-based verification 

- Functional instead of axiomatic 

| model oriented instead of property oriented 
| designed to scale up (stepwise refinement) 

| easier for programmers to understand 

- 2 pieces 

1. Deriving program functions 

| Trace tables (basically manual symbolic 
execution) 

| Recurson instead of loop Invariants 

2. Module-oriented 

| abstract data types 

| constraints/closure on state data (abstract 
state machine) 




Cleanroom 
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Other Projects and Approaches 

• Application above the code level 

- Development of a "Box Structures" design 
language 

- Development of a "Box Structures" approach to 
requirements 

- Results 

| SA/SD approach to design most popular new 
approach 

| Requirements still written in English 

• Emphasis on SEW concepts 

— Concepts generally well accepted 
~ Loss of rigor reduces mathematical basis 



Note on Quality Emphasis 


• Software quality has extreme emphasis 


- Great emphasis on process improvement 

- Serious attention given to quality goals and 
measurement 


- Quality motivation programs 


| awards and recognition 


| Manned Flight Awareness program 


• There is willingness to work hard and invest for quality 


• The question is not what or how much but how 


- FM is generally perceived as not helping 


Au9>97 


Conclusions 


• Conclusion: Technology Transfer is very hard, even 
with 

- extensive education 

- tools support 

- demonstrated successes 

• Possible future directions 

- More consulting ("hand holding") (product 
champions) 

- Use only a core group (FM may just not be for 
everybody) 

- Require use of FM (selected groups) 

* Success story dose to home 

| technology transfer diminishes rapidly as a 
function of distance 

| long term committment is required (success 
story requires continued follow-up) 

- Different formal method(s) 

- Different tools (e.g. t theorem prover) 


Au^W 
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Reliable Computing Platform 


Ben DiVito 

ViGYAN 
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failure prob < io“® for 10-hour mission 






Hierarchical View of a Flight Control System Application Task 
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Construct reliability model to quantify reliability estimate 











Design Philosophy Formal Methods is Enabling Technology For 
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Reliable Computing Platform RCP’a Sequence Of Operation 
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Bounded Asynchrony 
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US Transition Relation RS State Vector 
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Clock Synchronization 
Verification and Implementation 


Paul Miner 

Systems Validation Methods Branch 
NASA Langley Research Center 
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Simulation of Algorithm Simulation of Algorithm 
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tw • Implementation uses off-the-shelf communication circuits and 

(raa) r 

PLDs. 

Upset Response, No Permanent Faults « Simulation results confirm behavior predicted by theory. 
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NASA’s Strategy for Technology Transfer 


Sally Johnson 

Systems Validation Methods Branch 
NASA Langley Research Center 
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NASA’S STRATEGY FOR 
TECHNOLOGY TRANSFER 


by 

Sally C. Johnson 
NASA Langley Research Center 


GOAL 


Technology Transfer to Industry 

One of NASA’s major goals is to provide the U.S. aerospace indus- 
try with the tools and techniques they will need to be world-class 
competitors in the coming decades. 
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Technology Transfer 


KXISTINO 

I'OUMAI. MinilODS 
TOOI.S AIIXIINIOUILS 


INDUSTRY 

NliliDS 



l-'ORMAI. METHODS 
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UKSKiNIRS 


Working with Industry 


• Hoeing Fill hardware verifical ion 

• Hot ing SVM hardware verification 

• ( ’SDH/Olt A Scoreboard hardware verification 

• OKA Verification of Ada application software from NASA (Jod- 
dard and Johnson 

- Formal specification and vorificat ion of calendar utilities 

- Mode-control panel logic of Hoeing 7J7 experimental system 

specified in barcli 

• Currently pursuing future projects 


109 



Working with the FAA 


• Digital Systems Validation Handbook Chapter 

• Tutorial presentation to SWAT (Software Advisory Team) 

• Formal specification of GCS application 

• RTCA committee DO 178B standard 
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Verification of FTPP Scoreboard 

and Spectool 

Mark Bickford 

Odyssey Research Associates, Inc. 


Ill 
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The FTPP Logical Configuration 
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Abstract View of the Scoreboard I ! ( Actual Behavior 
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Controller state Machine 
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Proof of Msg Lemma: 
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ORiGSNAL IW'C IS 
OF POOR QUALITY 


Proof of Vtemma: 
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Phase 2: 
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Boeing’s Work in Formal Methods 

Dave Fur a 

The Boeing Company 
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Application of Formal Methods within the 
Boeing Defense & Space Group 
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FTEP Processor-Memory Module p,u Specification Hierarchy 
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t-DCAl , 0C*SuttQ - » A modeling approach wit identified for the IPttf ftefttiQI 

(h:limt. (SUM (M) » PhAlt >» Oil! | SUM I) A 

(Q i sj Sum (i+i^ • A prototype translator was developed and used to convert, into HOL, 

suitably formatted descriptions written In the simulation language M. 
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DO-178B and Formal Methods 

George Finelli 

Assistant Head, System Validation Methods Branch 
NASA Langley Research Center 
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DO-178B AND FORMAL METHODS 
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- Software Development q.q Software Duality Assurance Process 

- Software Verification g.o Certification Liaison Process 

- Quality Assurance and Configuration Management 10 0 Airborne System 

11.0 Software Life Cycle Data 
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Introduction to 

the Boyer-Moore Theorem Prover 

Warren Hunt 
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In general, a mathematical logic is defined by Infix Syntax 

• a formal language, (Q0OTIKMT (TUCKS V (SUBl H)) 2) 

• a set of axioms expressing assumed truths in the language, is printed as 
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Introduction to PVS 

Natarajan Shankar 

SRI International 
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Specification and Verification using PVS 


Outline 


N. Shankar 
sha nkarQcsl . srl . com 


This talk is a short tutorial on specification and 
verification, using PVS as an illustrative example. 

• Background to PVS 


Computer Science Laboratory 
SRI International 


• Overview of PVS 

• Some Examples 


i 
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Background: Past Experience 

Considerable accumulated experience on 
verification at SRI 

Systems developed at SRI include: Boyer-Moore 
Prover, HDM, OBJ, STP, EHDM, etc. 

Other Systems used include: Affirm, RRL, 
Gypsy, Muse, etc. 

Verifications include: Byzantine fault-tolerant 
clock synchronization, Byzantine Agreement, 
Gbdel's first incompleteness theorem, and many 
others. 


Background: EHDM 

Designed at SRI around 1984. 

A specification environment based on 
higher-order logic with parametric modules, 
implementation mappings, Hoare logic prover, 
etc. 

Theorem prover based on skolemization, manual 
instantiation, and Shostak's decision procedures. 

Example verifications include: Byzantine 
fault-tolerant clock synchronization, Ramsey 
theorem, Byzantine Agreement, Fault-masking 
and Transient recovery, etc. 


3 4 


150 


Background: Lessons Learnt 


PVS 


Decision procedures are extremely useful but 
only a small part of what is needed. 

Highly automatic theorem provers are 
inappropriate: difficult to control, and provide 
very little useful feedback. 

Low-level proof checkers are Inefficient (both in 
machine and human terms), and also fail to yield 
a satisfactory proof. 

Logics with limited expressibility are easily 
mechanizable, but place a large burden on the 
specifier. 

Some highly expressive notations are nice for 
pencil-and-paper work, but might be difficult to 
adequately mechanize. 
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PVS: Overview 

PVS has been used to check proofs of 

• the Boyer-Moore majority algorithm 

• ordered binary tree insertion 

• a version of the Schrbder-Bernstein theorem 

• Byzantine Agreement 

• a pipelined processor (due to Saxe), and 
other hardware examples. 

These proofs can typically be completed in less 
than a day. 


Started In mid-1990. 


The goal was to combine clear notation with a 
productive proof development environment to 
produce machine-checked, yet "humanly 
readable" proofs. 


PVS was primarily influenced by EHDM, but also 
adapts ideas on language and inference from 
IMPLY, Boyer-Moore prover, LCF, HOL, ML, 
Nuprl, Veritas, OBJ, and many other systems. 


PVS consists of a core language definition, 
parser, typechecker, and proof checker. 


Contributors to PVS include Sam Owre, John 
Rushby, Friedrich von Henke, David Cyriuk, Judy 
Crow, Carl Witty, and Steven Phillips. 


6 


Overview: Decision Procedures 

PVS proofs make heavy use of arithmetic 
decision procedures. Any theorem below is 
automatically proved, conjectures are either 
false or unproved by decision procedures. 

arltliMtlc : THEORY 
BEGIN 

1,1,91 YAH nuabtr 

trltfc: THEOREM 

x < 2*y AID y < S*x IMPLIES 3*x < li*x 

badarlth : CONJECTURE 

x < 2*y AHD y < 3*x IMPLIES 3*x < J7*r 

b*darlth2 : CONJECTURE 

x<0 AMD y<0 IMPLIES x*y>0 

baddlx: CONJECTURE 

(x/y) > x IMPLIES x > (y*x) 

fooddlx : CONJECTURE 

y/*0 AND (x/y) > x IMPLIES x > (y*x) 

uothirdifi THEOREM 

y /• 0 AND (x/y) > (x/y) IMPLIES ((*-x)/y) > 0 

1, j, k: TAR tat 
ibtarltfe: THEOREM 

2*1 < 5 AND 1 > 1 IMPLIES 1 - 2 

bftdirltfcS: CONJECTURE 

2«x < S AND x > 1 IMPLIES x ■ 2 
END aritkaxtlc 


8 


151 


Type Correctness Conditions 


Denominator for division must be non-zero. 
Typechecking the previous theory generates type 
correctness conditions. baddiv_TCCl is not 
provable, hence a type error. 

irlthi**tic: THEORY 
BEGII 

x» VAR nu«b*r 

with: THEOREM 

x < 7 * y AMD 7 < 9 * v IMPLIES S * x < 18 • ▼ 
badarith : CONJECTURE 

x < 7 * y AID jr < 3 * v IMPLIES 3 * x < 17 • ▼ 

badarith3 : CONJECTURE 

x < 0 AID y < 0 IMPLIES x • y > 0 

baddir: CONJECTURE 

(x / y) > ▼ IMPLIES * > (y • v) 

t Snbtyp* TCC g*n*nt*d for y 

baddW.TCCl: OBLIGATION (FORALL (y: nm>b*r) : y /» 0) 
gooddlrt CONJECTURE 

y /- 0 AND (x / y) > * IMPLIES x > <y * v) 
uotktrdiv: THEOREM 

y /■ 0 AND Ot / y) > (r / y) IMPLIES «x - O / y) > 0 
i, j* h: VAR int 

intar ith: THEOREM 7 * i < 6 AND i > 1 IMPLIES i ■ 7 
badarithS: CONJECTURE 2 * x < 5 AND x” > i IMPLIES x » 5 


END arithmtic 


Example: Binary Trees 

Binary trees can be defined as abstract 
datatypes. 

The following datatype declaration introduces 
the constructor leaf with recognizer leaf?, and 
constructor node with accessors val, left, and 
right, and recognizer node?. 

Typechecking this datatype declaration 
generates the theories binary_tree_adt and 
binary-tree_rec_mod (shown below). 

bixiry.tr •« [T : TYPE] : DATATYPE - - 
BEGIN 

lnl : l*lf? 

nod*(val • T, loft : binary. tr«a, Tight : binary.tr**) : nod* 1 * 

ERU binary.tr** 
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Abstract datatype theory 

Mnary.tr**.*dt [T: TYPE): THEORY 
BEGIN _ _ _ 

b inary. tr**: TYPE ‘ 

l*af?, nod*?: PREDCbiniTy.tr**] 
l**f : <l*if?) 

nod*: tT, biniry.tr**, biniry.tr** -> (nod*?)] 

Til: [(nod*?) •> T] 

l*ft: [(nod*?) -> biniry.tr**] 

right: t(xod*t) -> bimry.tr**] 

l*if .*xt*nalon*lity : AXIOM 

(FORALL <l**f?.Tir: (l*il?)>: l*ii « l*if?.Tir) 

nod«.*xt*niion*lity : AXIOM 

(FORALL (nod*?.Tir; (nod*?)): 

nod«(Til(nod*?.Tir) , l*ft(nod*?_Tir) , right (nod*?.Tir)) 

■ xod*?_Tir) 

ril.nod* : AXIOM - - 

(FORALL (nod*l.riT: T) , (nod*2.Tir: bimry.tro*) , 
(nod*S.Tir: biniry.tr**): 

Til(nod*(nod«l.T*r , nod*3.T*r, nod*3.nr)) 

- nodal.rar) 

l*ft.nod«: AXIOM 

(FORALL (nodoi.Tir: T) , <nod*3.Tir: bimry.tr**), 
(nod*S.Tir: binsry.tr**): 

l*ft(nod*(nod*l.Tir, nod*3.T*r, nod*3_T*r» - nod*3.Tir) 
right. nod*: AXIOM 

(FORALL (nod*l_T*r : ?) , (nod*2.T*r: bimry.tr**), 

(nod*3.rir: binary. tr**) : - 

right(nod*(nod*i.T«r , nod*2.Tir, nod*3.rar)) • nod*3_rar) 


biniry .tr**.di* joint : AXIOM 

(FORlLL (biniry.tr**.Tir: blniryjLmih : 

NOT (l*il?(bin*ry.tro*.Tir) AND nodo? (bimry.tro* .nr))) 

blniTj_tr**.ineln*lv*: AXIOM 

(FORALL (bimry.trm.Tir: biniry.troo) : 
l«if?(bimry.tr**.Tir) OR nod*?(bimry.troo.Tir)) 

biniry.tr**. induct ion: AXIOM 

(FORALL (p: PRED [bimry.tro*] ) : 
p(l*if) 

AMD 

(FORALL (nod«l.Tir: T), (nod*2_r*r: bimry.tr**), 
(nodoS.Tir: bimry.tr**): 
p(nod*2.Tir) AND p(nod*3_Tir) 

IMPLIES p(nod* (nod* I.Tar , nod^2.Tnr , nod*3.Tir) ) 5 
IMPLIES (FORALL (bin*ry.tr**.Tir: bimry.tr**) f ” 
p(blniry.tr*«.Tir)) ) 
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blMr (lMlY.fu : nat) , 

(nodot.fnn: [T, nat, nat -> nut])); 
[blnary.traa -> not] * 

LAMBDA (blnary.traa.Tar: blnary.traa) ! 

CASES blnary.traa.Tar Of 
laaf: laafT.fnn, 

nada (nodal. Tar, noda2.Tar, nodaS_rar): 
noda?.fun(nodal.Tar, 

binary .tran.nat.rncOaafT.fun , 

nodaT.f un)(noda2.Tar) , 
binary.trao.nat.rac (laafT.fnn , 

nodaT.f on) (nodaS.aar) ) 

EIDCASES 

blnary.traa. ordinal.rae( (laafT.fnn: ordinal) , 

(nodaT.f nn: [7, ordinal, ordinal 
-> ordinal])): 

[blnary.traa -> ordinal] ■ 

LAMBDA (blnary.traa.Tar : blnary.traa): 

CASES blnary.traa.Tar DP 
laaf: laafT.fnn, 

noda (nodal. aar , noda2.Tar, nodoS.rar) : 
noda?.fnn(nodal.Tar , 

blnary_traa.ordinal.roc (laaf?. Inn, 

nodaT.f on)(noda2_Tar) , 
binary. traa.ordinol.rac (laafT.fnn, 

noda?.fnft)(nodaS.Tar)) 

EIDCASES 


Recursion combinator 

binary. traa_rac.»od[T : TTPE , rang a : TYPE]: THEORY 
BEOII 

DSHD binary. traa.adt[T] 
binary.traa.rac( (laaf Y.f nn : ranga) , 

(nodaT.f nn: [t, ranga, ranga -> ranga])): 

[blnary.traa -> ranga] ■ 

LAMBDA (blnary.traa.Tar: blnary.traa): 

CASES blnary.traa.Tar OF 
laaf: laaf?. fan, 

noda (nodal.Tar , noda2.var, nodaS.rar) : 
noda ?.fnn(nodal. Tar , 

binary .traa.rac (laaf ?_f on , nodaT.f nn) (nodal.Tar) , 
binary .traa.rac (laaf T.fnn, noda?.fnn)(nodaS.»ar)) 

EIDCASES 

EID blnary.traa.rac.nod 


EID blnary.traa. adt 
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Ordered Binary Trees 

obt [T : TTPE, <• : (total.ordar?[T])] : THEORY 
BED II 

DSHD binary.traa.adt , binary. tTto.rac.aod 
A, B, C: TAR blnary.traa [7] 
i, y, a: YAH T 
pp: TAR PRED[T] 

chackalK (pp : PRED [T] ) , A): bool • 
bi nary. traa.rac (TRUE , 

(LAMBDA x, (a, b : bool): 

(a AID b AID pp(x))))(A) 
i, j, k: TAR nat 
alxa(A) : nat ■ 

binary. troo.roc(0, (LAMBDA x, 1, j: 1 ♦ J ♦ 1))(A) 
ordarad?(A) : RECURSIVE bool « 

(IP nodo?(A) TKEI (chockall ((LAMBDA y: y<»Tal(A)), loft(A)) AID 
ckockall ((LAMBDA y: Tal(AX-y), right (A)) AID 
oTdorod?(loft(A)) AID ordorod?(rlght(A))) 

ELSE TRUE EIDIF) 

BY siza 

lnaort(x. A): RECURSIVE blnary_troo[T] ■ 

(CASES A OP 

loaf: nodo(z, laaf, laaf), 

noda(y, B, C) : (IP x<*y THE! noda(y, lnsart(x, B), C) 

ELSE noda(y, B, lnaart(x, C)) 

EIDIP) 

EIDCASES) 

BY (LAMBDA x. A: aiza(A)) 

ordaradT.lnsart.atap: FORMULA 

pp(x) AID chockall (pp, A) IMPLIES 
chackalKpp, inaart(x, A)) 

ordaradT.lnaart : FORMULA 

ordarad?(A) IMPLIES ordarad?(lnaart(x. A)) 

EID obt 

13 


Example Proof 

ordorodT.lnaort : 

| 

\ 1 ) (FORALL (x: T), (A: binary.troo) : 

ordorodT(A) IMPLIES ordoTod?(inaort(x , A))) 

Rnlo? (Induct ” A”) 

Inducting on A, 

thia yiolda 2 snbgoala: 

ordorodT.lnaort . 1 : 


(1) (FORALL <x: T): ordoradT(loaf ) IMPLIES ordorod?(inaort(x , loaf))) 
RnloT (skoleml) 

For tko top qnantlfior in 1, *o Introduco Skolon conatanta: (xf3) 
thia ainpliflaa to: 
ordorodT.lnaort . 1 : 

I 

(1) ordorodT(loaf) IMPLIES ordorodT(lnaort(xf3. loaf)) 

RaloT (dslmp) 

Applying dlajanctiaa a inplifl cation, 
thia aiapllf ioa to: 
ordorodT.lnaort . 1 : 

1*1} ordoradT(laaf) 

{1} ordorodT(lnaort(xtS, loaf)) 

RuloT (rewrite "Inzert") 

Rovritlng nalng lnaort, 
thia alnpllfioa to: 
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or dorodt.inoort . 1 : 


[-1] ordorod? (loaf) 


{1} ordorod?(nodo(x!3, 1 •mi f !«*)> 

RoioT (rewrite "ordered?" +) 
Rovritlng using ordsrod?, 
this siaplifio* to i 
ordorod?. insort .1 : 


t-1] ordorodt(loaf) 


<0 


(chockall ((LAMBDA (y : 7) : 7 <■»**>» 

AID chackalK (LAMBDA (y: T) : x»3 <• y) . *••*> 
AID ©rdarod?(loaf) AID ordorod? (loaf )) 


Rato? (assert) 

Invoking decision procoduroa, 
thio siapllfiot to i 
ordorod?-insort.l : 

[-1] oTdorod?(loof ) - -- ■- •" 

ii\ chockalK (LAMBDA (y: 7): y <- **3), *••*) 

RID chockall ((LAMBDA (y: T) s x!3 <- j) . 1**« 

Hull? (auto-rewrlte " binary _tree_recfT, bool]") 
Installing autoaatic rowritoa: 
binary-txoo.roc [T , bool] , 
this siaplifioa tot 
ordorod?.ln*ort .1 i 


[-1] ordorod? (loaf) 

[ 1 ] chockalK (LAMBDA (yi T) : y <- x!3), Haf) 

AID ckockalK (LAMBDA (y: T) : x!3 <■ y) , !••*> 


Rulo? (then (split) (rewrite "checkatT)) 
Splitting conjunctions, 
tkia ylolda 3 aobgoalo: 
ordor od?. I n s ort .1 .1 t 

t-il ordorod? (loaf) 

| 

(1) ckockalK (LAMBDA (y: 7): y <« x*3), loaf) 
Rovritlng using chockall, 

Tkia coapletoa tho proof of ordorod’.inoort . 1 . 1 . 
ordorod?. Insort A .2 : 

[-1] ordorod? (loaf ) 

I 

(1) chockalK (LAMBDA (y: 7): *'5 <• y), loaf) 
Rovriting using chockall. 

This coiaplotoa tho proof of ordorod?. inaart . 1 .2. 


This coaplotoa tho pToof of ordorod’.insort . 1 , 


ordorod?. insort .2 i 


(1} (FORALL (nodal. oar: 7), (nodoJ.vor: Mnary-trao) , 

(nodoS.var : binary _troo) : 

(FORALL (a: T): 

ordorod? (nodoS.var) IMPLIES oTdorod?(insort(x , nodo3.vor)» 

AID 

(FORALL (x: 7): 

ordorod ? ( nodo 3_vor) 

IMPLIES ordorod? (InaoTt (a, nodoS-var))) 

IMPLIES 

(FORALL (x: 7): 

ordorod? (nodo (nodal _rar, nodol.var, nodo3-var» 

IMPLIES ordorod?(insart(x. nod o< nodo 1-Tar, 
nodo2.oaT , 
nodo3_var))))) 

Rulo? (skoleml) 

For tho top quantifior in 1, vo introduco Skolaa constants: 

(nodol-varfA nodol.vnr'S nodoS.TarfS) 
this alaplifios to: 
ordorod?. Insort .3 : 

| 

( 1 } (FORALL (x: 7) t , ..... 

ordorod? (nodol.var ! 6) IMPLIES ordorod?(inoort(x, nodo3 = aar « 6))) 

AID 

(FORALL (x: 7): 

ordorod? (nodoS.var ! 6) 

IMPLIES ordorod? (inoort(x, nodo3.var !«))) 

IMPLIES 

(FORALL (x: 7)s 

ordorod?(nodo(nedol.Tsr?4, nodo2_var!5, nodo3.var‘«)5 
IMPLIES ordorod?(inoort(x , nodo(nodol.var!4, 
nodoS.var! 6, 

nodo3_var!6)))) ___ _ 


Rulo? (dslmp) 

Applying disjunetivo siaplif ication, 
this siaplif loo to: 
ordorod?. insort .2 : 

{-1} (FORALL (xi T): 

ordorod? (nodal.var * 6) 

IMPLIES ordorod? (insort (x , nodol.var ! 6))) 

{-2) (FORALL (x: 7): 

ordorod? (nodoS.var ! 6) 

IMPLIES oTdorod?(lnaort(x, nodo3.va r !g)5 ) 

I 

(1) (FORALL (x: T): 

ordorad?(noda(nodai-rar M , nodo2.var!5, nodaS.var *6)) 
IMPLIES ordoTod?(insart(x , nodo (nodo l.rarfd, 
nod#2_var !5, 
nod#3.var !6)))) 

Rulo? (skoleml) 

For tho top quantifior in i, no introduco Skolaa constants: (x!7) 
this siaplifios to: 
ordar*d?_insort.3 : 

t-1] (FORALL (x: 7)? 

ordorod? (nodol.var! B) 

IMPLIES ordorod?(lnsort (x, nodol.var ! 6) )) 

[-2] (FORALL (x: 7): 

ordered ?(nodo3.var ! 8) 

IMPLIES ordered?(insert(x. nodoS.var !6))) 


(lj ordered? (node (nodol.var ?4, node2.Tar!5 t nodo3_var!e)) 

IMPLIES erdered?(ineert(x!7, n ode ( node 1-var! 4, 
nodol.var !5, 
no4o3.var !B55) 
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Bolat (rewrite "ordered? - -f) 

IU writing oalng ordwtdt, 
this aivplifiaa to: 
ordaradt.lnaart .2 : 

[-13 (FOBALL (x: T)s 

ordaradt(noda2.war1S) 

IMPLIES ordaradt(lnoart(x, nodaS.war 15))) 

[-23 (FOR ALL (x: 7): 

ordaradt (nodaS.war I 8) 

IMPLIES ordaradtOnsart (x, nodaS.war *8))) 

a] (chackall ((LAMBDA <y: 7): j <« nodal.war 14) , noda2.war!6) 

AMD chaekalK (LAMBDA (y: 7): nodal .war! 4 <• y), nodaS.war 18) 
AID ordaradt (noda2_war 18) AID ordarad?(noda3.warl8)) 
IMPLIES ardor ad t( lnaart (x 17 , nada (nodal.war 14, 
nodtS.warlB, 
nodaS.war 18))) 

kola? (dslmp) 

Applying dlajnnetlwa aiaplifl cation, 
thla slvpllflat to: 
ordaradt.lnaart .2 : 

[-11 (FOBALL (*: 7): 

ordaradt (nodo 2-war 1 6) 

IMPLIES ordaradt(in#art(x, nodaS.war 16))) 

[-2] (FOBALL (x: 7): 

ordaradt(noda3.war !6) 

IMPLIES ordaradMinoartd, nodaS_war!S)3) 

(-3) chaekalK (LAMBDA (y: 7): y <• nodai-war'4) . noda2.war!5) 

(-4) chaekalK (LAMBDA (y: 7): nodal. war !4 <- y), nodaS.war 18) 

(-5) ordaradt (nodaS.war 16) 

{-•} ordaTadt (nodaS.war 16) 


{1} ordorod?(lnaort(x!7 , noda(nodol.war?4, 

noda2.war!S ( 
nodaS.war 16)) ) 


Bolat (rewrite "Insert" +) 

Bavriting nslng lnaart, 
thla alaplifiao to: 
ordarodt.inaart.2 : 

[-13 (FOBALL (x: 7): 

ordaradt (noda2.war ! 6) 

IMPLIES ordaradtdnaartd, noda2.war !B))) 

[-2] (FOBALL (x: 7): 

ordaradt (no da 3. war ! 6) 

IMPLIES ordaradt (lnaart (x , noda3.war!6))) 

[-31 chaekalK (LAMBDA (y: 7): y <- nodal.war!4) * noda2.waT!6) 

[-4] ehackalK (LAMBDA (y: 7): nodal.war!4 <• y) . nodaS.war 18) 

[-83 ordaradt (noda2.war ! 8) 

[-83 ordaradt(noda3_war 18) 

| 

{1} ordaradt ((IF x!7 <« nodal.war*4 
THEM 

noda (nodal-war 14, 

lnaart(x!7, noda2.war ! 8) , 
nodaS.war 18) 

ELSE 

noda (nodal-war ! 4 , 
noda2.war !B , 

lnaart(x!7, noda3.war!8) ) 

DID1F)) 

Bolat (lilt- If) 

Lifting IF-condltlona to tha top lawal, 
this sinpllflas to: 


ordaradt. lnaart .2 : 

[-13 (FOBALL (xi 7): 

ot dar ad t (noda 2-war ! B) 

IMPLIES erdaradt( lnaart (x, uoda2_war !B))) 

[-23 (FOBALL (xr 7): 

ordaradt (nodaS-war 18) 

IMPLIES ordaradt(inaart(x, noda3.war!8))) 

[-33 ehackalK (LAMBDA (y: 7): y <- nodal.war!4) , noda2.war!8) 

[-43 chaekalK (LAMBDA (y: 7): nodal.waT!4 <- y), noda3_war!8) 

[-83 ordaradt (noda2-war! 8) 

[-83 ordaradt (nodaS.war 18) 

I 

(1) IF x!7 <• nodal_war!4 
TIES 

ordaradt(noda (nodal.war 14, 

lnaart (x! 7, noda3.war !8) , 
nodaS.war 18)) 

ELSE 

ordaradt (noda (nodal. war !4, 
noda2.war!8, 

lnaart(x!7, noda3.war!8))) 

EIDIF 

Bolat (propS) 

By propoaltlonal olnpllf leatlon, 
this yialds 2 sobgoals: 


ordaradt.lnsart .2. 1 : 


(-1) x!7 <* nodal.war 14 

[-23 (FOBALL (x: 7): 

ordaradt (noda2-war ! 8) 

IMPLIES ordaTadt(inaart(x, nodal.war 18))) 

[-31 (FOBALL (x: 7): 

ordarad t(noda3_war ! 8) 

IMPLIES ordaradt (lnaart (x, noda3.war 18))) 

[-43 ehackalK (LAMBDA (y: 7): y <- nodal.war 14) , nod#2_war»6) 

[-83 chaekalK (LAMBDA (y: 7): nodal.war ?4 <• y), nodaS.war 18) 

[-83 ordaradt (nodaS.war 1 6) 

[-73 ordaradt (nodaS.war 1 8) 


{1} ordaradt(noda(nodal_war 14, 


lnaart (xi 7, nodaS.war 16) , nodaS.waT !8)) 


Bolat (rewrite "ordered?" +) 
Bavriting oalng ordaradt, 
this alapllfiaa ta: 
ordaradt. lnaart. 2.1 : 


[-13 x!7 <■ nodal.war 14 

[-23 (FOBALL (x: 7): 

ordaradt (noda 2. war 1 8 ) 

IMPLIES ordorodt(lnsort(x, nodo2.war !8))) 

[-33 (FOBALL (x: 7): 

ordaradt ( nodaS.war 1 8) 

IMPLIES ordaradt( lnaart (x , nodaS.war 18))) 

[-43 ehackalK (LAMBDA (y: 7): y <• nodal.war‘4) , nodaSwar'S) 

[-83 chaekalK (LAMBDA (y: 7): nodal.war'4 <• y), nodaS.war 18) 

[-83 ordaradt (nodaS-war 15) 

[-7] ordaradt (nodaS.war 18) 

I 

(1) (chaekalK (LAMBDA (y: 7) : y <- nodal.war 14) , 
lnaart (x! 7, nodaS.war 15)) 

AID cfcaekalK (LAMBDA <y: 7): nodal.war !4 <- y) , nodaS.war «8) 
AID ordaradt(insart(x!7, nodaS.war 16)) 

AID ordaradt (nodaS.war 18)) 
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ordsrsd?_inssrt .2. 1 : 


Ruls? (quant?) 

Found substitution: 
l gsts *17, 

Instantiating quantified variables, 
this simplifies to: 
ordsred?-inssrt .2 . 1 : 

[-13 x!7 <- »odei-xur!4 

(-2) ordered? (nod«2.Tur ! 6) IMPLIES ordered?(insert(x«7. nods2_var »6)) 
[-33 (FOBALL (x: 7): 

ordsrsd?(nod«3.vur16) 

IMPLIES ordsrsd? ( insort (x, nods3_wl6))) 

[-43 chsckulK (LAMBDA (y: 7>: y <- nodui.vur' 4) , nods2.*ar ! 6) 

[-63 chsckulK (LAMBDA (y: 7): nodsl-var!4 <» y) . nod*3-»ur!6) 

[-63 ordsrsd? (nod#2-*ar ! 6) 

[-73 oTdsrsdt(nodsS-TurlB) 

[13 (ehockall ((LAMBDA (y: 7): y <* nodol.TUr!4) 
lns*rt(x!7, node2_vur f 6)3 

AMD chsckulK (LAMBDA (y: 7): nodsl.eur‘4 <- y>. nods3.var*6) 
AMD ordsrsd?(insert(x!7, nodiT^var 1 6) ) 

AMD ordered? (noduS.fur !B)) 

Buis? (prop$) 

By propositional simplification, 
this simplifies to: 


Buis? (rewrite "ordered?” 4-) 

Rewriting using ordsrsd?, 
this simplifies to: 
ordsTsd?.inssrt .2.2 : 

[-13 (FOBALL (x: 7): 

OTdsrsd?(nods2-x*r!6) 

IMPLIES ordsred?< insert (x, nods2.T*r»6))) 

[-23 (FOBALL (x: 7): 

ordsrsd? (nodeS.vuT !6) 

IMPLIES ordsrsd?(inssrt(x, nods3_Tar»6))) 

[-S3 ehsckull ((LAMBDA (y: 73 : y <• nedsl.Tur *4) , node2-var!6) 

[-43 ehsckull ((LAMBDA (y: 7): nodel.vurH <• y>, nodeS-varfe) 

[-63 ordsrsd? (nods2_rur ! 6) 

[-63 ordsrsd? (nodsS.rur ! 6) 

[1) xf 7 <* nodsi-Turfd 

{2} (ehsckull ((LAMBDA (y: 7): y <- nodsi.rur‘4) , nods2.vur»6) 

AMD 

chsckulK (LAMBDA (y: 7): nodsl.Tur‘4 <* y). 
ins*rt(x!7 , nodsS.xur !6)) 

AMD ordered ?( node 2-tar 1 6) 

AMD ordsrsd?(inssrt (a! 7 , nodeS-var »6))) 

Buis? (quant? -2) 

Found substitution: 
x goto x'7. 

Instunt luting quuntifisd ruriublss, 
this simplifies to: 


{-1} ordsrsd? (inssrt(x! 7, nods2_Tur !6)) 

[-23 *17 <• nodsl.rur>4 

[-3) (FOBALL (*: 7): 

ordsrsd? (nods S.var ! 6) 

IMPLIES ordsrsd?( lnssrt (x , nodsS.sur *6))) 

[-43 ehsckull ((LAMBDA (y: 7): y <- nodei.Tur'4) , nods2_vur»6) 

[-63 chsckulK (LAMBDA (y: 7): nodei-varU <- y) f nods3-vur!6) 

[-63 ordered? (nods2.vur 16) 

[-7] oTdsrsd?(nodsS_rur!B) 
l- 

{1} chsckulK (LAMBDA (y: 7): y <» nodsi.vur'4), = 
lnssrt (x!7, node2.ver *6)) 

Buis? (rewrite " ordered? Jnsert -step”) 

Rewriting using ordsTsd?-inssrt_stsp, 

This coMplstss ths proof of ordsTsd?_inssrt.2.1. 

ordsrsd?_lnssrt .2.2 : 

[-1] (FOBALL (*: 7): 

oTdsrsd?(nods2_sur * 6) 

IMPLIES ordsrsd?(inssrt(x, nods2_rar ‘6))) 

[-2] (FOBALL (x: 7): 

orduTsd?(nodu3-Tur ! 6) 

IMPLIES ordsrsd? (insert(x, nodsS.vur *6)3 > 
t-3) chschulK (LAMBDA (y: 7): y <« nods! -war *4) , nods2-»ur!6) 

[-43 ehsckull ((LAMBDA (y: T) : nod«i.var!4 <- y), nods3_Tur*6) 

[-63 ordursd?(nods2.rur f S3 
[-63 ordsrsd? (nodsS.rur *6) 

(1} x!7 <* nodsl-rurl4 -- 1 ; =- — ’ ■ 

{2} ordsrsd?(nods(nodsi-rur !4, 

node2-var!6, = i:_ 
lnssrt(x!T, nodsS.vur !6))) 


ordsrsd?. lnssrt .2.2 : 

[-13 (FOBALL (x: 7): 

ordsrsd ? (nods 2_rur ? 6) 

IMPLIES ordered? (insurt(x, nods2_rur *5333 
(-2) ordsrsd? (nodeS.var \ 6) IMPLIES ordsrsd?(inssrt(x !7 , nods3_»UT ?6)) 
[-33 ehsckull ((LAMBDA (y: 7) : y <- nodal-var !4) , nods2-Tur'6) 

[-43 ehsckull ((LAMBDA (y: T): nodui_rar*4 <« y), nods3_rur!6) 

[-6} ordered? (node2_var» 6) 

[-63 ordsrsd? (nodsS.var ! 6) 

| 

[13 x!7 <■ nodsi.xur!4 

[23 (ehsckslK (LAMBDA (y: T) : y <« nodsl.var !4) , nods2.Tur»6) 

AMD 

chsckulK (LAMBDA (y: 7): nodal -war U <- y), 
insert (x!7, nods3.Tur?6)) 

AMD ordersd?(nods2.var !6) 

AMD ordersd?(insert(x!T , nodeS.var ? 63 ) 3 

Buis? (propf) 

By propositional simpllf icution , 
this simplifies to: 
ordursd?-inssrt .2.2 ; 

{-1} ordsr*d?(lns*rt(xt7, nodeS.var !6)) 

[-23 (FOBALL (x: T): 

ordsT#d?(nods2-vur !6) 

IMPLIES ordsrsd? (lnssrt (x, nods2_var *6))) 

[-33 ehsckull ((LAMBDA (y: 7): y <- nodsl.vur !4) , nod*2.vur!6) 

[-43 chuekull ((LAMBDA (y: T) : nodei-var*4 <• y), nod#3-*ar!6) 

[-6) ordsrsd? (noda2.vur f S) 

[-6] ordsrsd? (nodeS-vur !6) 

I 

[1) chsckulK (LAMBDA (y: 7): nodsi.v*rf4 <- y), 

inssrt(x*7, nodsS.varf 6)) 

[23 Xf7 <• nodsl.vur !4 
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R«l«T (rewrite " ordered? JniertJtep" ) 
ha writing using ordir«dT.liii<rtJt«p, 
this ilipliflH toi 
ordaradT. Inaart .3.3 : 

[-1) ordaradT(lnsart(x?7, noda3_rar? 0)) 

1-31 (TO0 AIL <x: T): 

ordsr ad ? < no 4a 3-rnr f 0 ) 

IMPLIES ordaradT ( inaart (x , nodaS.rar ! 6) ) ) 

[-3] chaekalK (LAMBDA (y: T)i y <« nodal.rnTU) . noda3_rar»6) 

[-41 chaehall ((LAMBDA (yi T): asdal.var'4 <- y). noda3.rar!0) 

[-0} ordaradT (noda3_rnr! 6) 

[-01 ordaradT (nodsS.rar ! 0) 

| 

(1) nodal.rar '4 <• x!7 

[31 cbackall ((LAMBDA (y: T) : aodal.rarM <- y), 

Inaart (xf7, nadaS-var !0)) 

[3J x!7'<» nadai_rnr!4 

Bala? (typepred "obt.t-") 

Adding typa constraint* for obt.<*, 
thia slapliflss toi 
ordaradT.lnaart .3.3 : 

(-1) total-ordaTt [Tl (abt .<») 

[-3] ordaTadT(insart(x?7, aodaS-rar !0)) 

[-3] (FOhALL (x: T) : 

ardaradT(noda3.rur ! 6) 

IMPLIES ordaradK Inaart (x , nadal.TXTt 6))) 

[-41 cbackall ((LAMBDA (y: T): y <• nadal.mTfd) , aoda3.rar!6) 

[-61 cbackall ((LAMBDA (y: T): nodal-ror!4 <« y), noda3.rnr!0) 

[-01 ordaradT (aods3-rar? 6) 

[-71 ordaradT (aadsS-rurtS) 

[1] nodal -Tar !4 <• x!7 

[31 chaekalK (LAMBDA (yt T)i nadai_rar!4 <- y), 

Inaart (x 17, nodaS.rar 10)) 

[3j x*7 <■ nodal.rar f4 


hula? (rewrite "to tel -order?") 
karri ting aaing total.ardarT, 
thia slMplifls* tas 
OTdsrodT.insart .3. 2 : 

(-1} FOhALL (x, y: T): x <- y Oh y <■ x 
[-23 ardaradt(insaTt(xl?, nodaS.rar !0)) 

[-31 (FOB ALL (x: T): 

ordar adf (nodal. vat ! 6) 

IMPLIES ordsr#dT( inaart (x, aadaS.rar » 6))) 

[-41 cbackall ((LAMBDA (y: T) : y <• nadal.rar 14) . noda2_rurf6) 

[-63 cbackall ((LAMBDA (y: T) t nodal.rnr!4 <- y) , noda3.rar!0) 

[-6] ordaradT (nsdsS.rar 16) 

[-7] ordaradT (nodaS.rar II) 


[11 asdal-rart4 <■ xf7 

[21 chaekalK (LAMBDA (y: ?): aodal.rarM <- y), 

Inaart (x (7 , nodaS.rar! 0) ) 

[31 x»7 <- nodal.rar M 

kola? (quant?) 

Found substitution; 
y gata x!7, 
x fata nodal.rar M , 

Inatant iatlnf quant If lad rnriablaa, 
thia alapllfiao ta: 


ordaradT.lnaart .2.3 t 

{-1} nodal.rar !4 <• xf7 OB x!7 <■ nodal.rar!4 
[-2} ordaradT(insart(x!7, aadaS.rar 1 0) ) 

[-31 (FOB ALL <x; ?): 

ordsrsd?(nodo3-rar!6) 

IMPLIES ardaradt ( inaart (x , nodaS.rar! 6))) 

[-41 cbackall ((LAKBD A (y: T): y <- nodal.rar 14) , noda2.rart6) 

[-61 cbackall ((LAMBDA (y: T): nodal.rar M <• y), noda3.rar!0) 

[-01 ordaradT (asda2-rar 16) 

[-7) ordaradT (nodaS.rar !0) 

[ll nodal.rar !4 <* **7 

[21 chaekalK (LAMBDA (y: T) : nodal.rar 14 <- y), 

Inaart (x (7, nodaS-rar ! 0) ) 

[3] x!7 <- nodal.rar !4 

Unlit (props) 

By propositional slapli 11 cation, 

Thia coaplataa tba proof of ordaradT.lnaart .3.2. 


Thia co^latss tba proof of ordaradT.lnaart .3 . 

q.e.d. 

Sara tba nor praafT (Taa or Bo) yaa 

Would you Ilka n brlaf printout of tba pTssfT (Too or Wo) yaa 
ordaradT. inaart r 

| 

{1} (FOMLl (x: T) , (A: blnnry.traa) : 

ordaradT(A) IMPLIES ordaradT (Inaart (x. A))) 

Inducting on A, 

which ylslds 3 aubgoala; 


ordaradT.lnaart. 1 j 


{1} (FOhALL (xt T): ordaradT (loaf) IMPLIES ordaradT ( inaart <x, laaf))) 

Par tba top quantifisr in 1, ra introduca Skolan constants; (x!3) 
Applying dlajunctlra simplification, 

Barrltlxg uaing inaart, 
karri ting uaing ordaradT, 

Inroblng dociaion procaduraa, 

Inatnlllng nutonatic rsvritssi 
binary _traa.ro c [T , baal] , 

Splitting conjunction*, 
which yislds 3 aubgoala t 

ordaradT.lnaart .1.1 : 

(-1) ordaradT (laaf) 


(1) chaekalK (LAMBDA (y: T): y <• x!3), laaf) 
Bavrlting using cbackall, 

Tbi* complatsa tha proof of ardor a4T. inaart. 1.1. 

ordaradT.lnaart .1.3 : 

{-1 } ordaradT (laaf) 

| 

(1) chaekalK (LAMBDA (y: T): x!3 <- y), laaf) 
karri ting uaing chaeknll. 

This csnplatsa tba proof of ordaradT.lnaart . 1 .3. 
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ordorodT.inoort .2 t 


| 

{1} (FOMLL (nodol.wnr: T), (nodo2_wor: binory.troo), 

(nodtS.vir: blnnry.tr oo) : 

(FOMLL (x: T) : 

ordorodt (nodo2.wor) IMPLIES ©rdoTodt (inoort (x , nodo2.wnr))) 

AID 

(FOMLL (x: T): 

ordorodt (nodoS.wor) 

IMPLIES ordorod?(lnoort(x, nodoS.wor))) 

IMPLIES 

(FOMLL <x: T)s 

ordorod?(n©do(n©dol.wor , nodoS.wor, nodoS.wor)) 

IMPLIES 

ordorodt ( inoort (x , nod© (nod© l.m , 
nod©2-wor, 
te4iS.Hr))))) 

For tho top qonntlf ior in i, wo int i o4oco_ftoIoi_coiit iiiti ; = = 

(nodol-Yor !4 nod©2_wor!B nodoS.wor!®) 

Applying dlijunetiwo oiwplificotion, 

For tho top qnnntiflor in 1, wo introdnco Skelow conotonto: (x»7) 

Ro writing noing ordorodt. 

Applying diojonctiwo oiaplifi cation, 

Ro writing noing inoort , 

Lifting IF-conditiono to tho top lowol, 

By propooitlonol oiwplificotion, 

which yioldo 2 oubgoolo : r r ._. 


ordorodT.inoort .2.1 i 


x!7 <» nodol .Tor M 
(FOR ALL (x: T): 

ordorodt (nodo 2- war ! 6) 

IMPLIES ordorodt(inoort (x, n»d«2.m!6))) 

(FOMALL (x: T): — — . 

" ordorodt(»odo3-war !6 ? ..J 

IMPLIES ordorod t(inoort(x, nodoS.wor!®))) f 

chocholl ((LAMBDA (y: th Jf <• nodol.worU) . nodoS.wor »l) 
chocholl ((LAMBDA (y: T) : nodoi.wor’4 <■ y), nodoS.wor »B) 
ordorodt (nodoS.wor !6) - 

ordorodt (nodoS.wor ?S) 


(i) ordorodt (nodo(nodol_wor !4, 

inoort(x!7, nodo2.wor ! 6) , 
nodoS.wor ! 6)) 


Ro writing using ordorodt, 

Inotont ioting qnojitifiod woriobloo. 

By propooitlonol oiiiplif 1 cot ion , 

Rewriting nolng ordorodt. inoort.otop , 

thlo cowplotoo tho proof of ordorodT.inoort .2.1 . 


ordorodT.inoort -2 .2 : 

{-1} (FOMALL (ni t): 

ordorodt (node 2. v or f 6) 

IMPLIES ordorodt ( inoort (x, nod*2_wor!5))) 

{-2} (FOMALL <x: T): _ 

ordorodt (nodoS.wor *•) 

IMPLIES ordorodt (Inoort (x , nodoS.wor !«))) 

{-3} chocholl ((LAMBDA <y: t) i y <• nodoi_wor!4) , nod©2-wnr>B) 

{-4} chocholl ((LAMBDA <y : T) : nodol.wor!4 <- y), nodoS.wor !fl) 

{-6} ordorodt (nodo2-wnrf 6) 

{-«} ordorodt (nodoS.wor !6) J ~~ 

, 

{1} xft <- nodol.wnr !4 

{2} ordorod?(n©do(n©doi-wor !4, 

nodo2-wnr!B, 

inoort(xf 7, nodoS.wor!®))) 

Ro writing noing ordorodt, 

Inotont ioting quant if iod woriobloo, 

By propooitlonol olapllficotion. 

Rewriting noing ordorodt.inoortJtop, . 

Adding typo c onotrolnto f or obt.d*, ' r 

Rowriting noing total. order? , 

Inotantlating qn ant if iod wariabloo, 

By propooitional oiaplif icatidB, 

Thlo coioplotoo tho proof of ordorodT.inoort .2.2. 


Q.E.D. 


Notes on the Language 

The core logic is a simply typed higher-order 
logic. 

Specifications are structured into parametric 
theories. 

Types can be parameters. 

Assumptions can be used to constrain the 
parameters. 

Set-like predicate subtypes can be defined. 
These make the domains and ranges of 
operations explicit. 

Theorem proving Is employed to carry out 
typechecking. 

Automatic facilitiy for generating abstract 
datatype theories. 

15 
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Conclusions 


Notes on the Proof checker 

Sequent representation for proof goals. 

Backwards proof construction by applying 
reductions. 

Heavy use of powerful decision procedures for 
equality and Inequality. 

Powerful primitive inference steps. 

Roughly twenty such steps. 

Strategy mechanism for encapsulating proof 
patterns. 

Ability to save and rerun proofs and partial 
proofs, and display proofs. 


PVS exploits the synergy between language and 
inference. 

The combination of powerful inference steps: 
decision procedures, rewriting, propositional 
simplification, etc., makes it effective to develop 
proofs that are both certified and convincing. 

Future goals: 

• To enhance the language to further exploit 
the inference capabilities 

• To generate readable proof outlines 

• To make proofs robust and easier to 
maintain 
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Logical Foundations of 
Computations over the Reals 


Richard Platek 
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Basic Problem 

What does it mean to say that a given program "computes" a real valued 
function such as sine x or e when it never really does? 

Classical answer: 

The program computes an approximation which is "sufficiently accurate" 

But what does that mean? 


©ORACofp, 1992 
St-0046 
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Two Fundamental Problem Areas 


□ Scientific Computations 

simulations, cacluation of engineering solutions, numerical experiments to 
explore theories, "number crunching" as part of experiments 

correctness is vital for decision making 

□ Embedded Computations 


computers as part of coninuous systems 
sense-compute-activate 



Botton Up Interpretation 

We reason at the level of the CPU and Floating Point processor so that we can 
calculate tight error bounds and we use numerical analysis techniques to 
estimate the accuracy of the computation. 

Perfectly fine, but too concrete 

A. Numerical Programs are not written in machine language or assembler. 
They are written in higher order languages like Fortran, C, Ada. The 
concrete analysis is not portable across CPU's. 

B. The concrete analysis is not portable across FPP’s. We should reason in 
terms of the IEEE floating point standard or the Brown model. 

In particular, our specs and proofs should be independent of the word length of 
the machine reals except in so far as the word length is knowable at the 
programming language level (e.g., Ada’s float’small) 


©ORACorp, 1992 
SL-0046 
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Verifying floating point computations 

□ Algebraic properties of floating point operations are a mess; and detailed 
descriptions are highly implementation dependent. 

□ Little automated support exists. 

□ We are incorporating support for both quantitative and qualitative error 
analysis into Penelope. 

This talk concerns qualitative error analysis. 


o ORA Corp, 1992 
SL-0046 
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Qualitative error analysis 

Intuitively: prove programs under the assumption that various sources of error 
are present but "negligible" 

Not equivalent to assuming that error is non-existent 


J 


©ORA Corp, 1992 
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Substitution in Approximate Reasoning 


If / is continuous, x « y => /(a;) ~ /(y) 


Therefore, 


x 


x\ and y ~ yi => a-' + y ~ 3; i + yi 


But comparisons are not continous 

iwt/ and x < z does not imply y < z 


©ORACorp, 1992 
SL-0D46 
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Mechanical translation of (many) facts of ordinary algebra to facts of 
approximate algebra. 

For example: 



translates to 


(x + lr £ a; 


© ORA Corp, 1 992 
SL-0046 
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Modeling Ada floating point operations 

Introduce specification predicate tor each basic operation 

fplus(x,y,z)'. 

z is a possible result of evaluating x * y 

Sample property: 

fplus( x, y,z) => z ~ x + y 


fle(x,y,b)\ 

b is a possible result of evaluating x <= y 


Sample properties: 

fle(x, y, true) => x < y 
fle(x,y, false) => x >y 


© OH A Corp. 1992 
SL-0046 
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For any a > 0, 


where 


s/a — limit^ooXt 


xq = a + 1 

x i+l = 1/2 (xi + a/x t ) 


K 

©ORA Corp, 1992 
SL-0046 
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Code for mysqrt 




function mysqrt (...) is 
x : float; 
begin 

if (a <= small) then 
return 0.0; 
end if; 
x a 4- 1 . 0 ; 

while (x*x-a >= small) loop 
x := (x+ (a/x) ) /2 . 0; 

end loop; 
return x; 
end mysqrt; 

Loop invariant annotation: 

small, x, a, (x 2 — a) ^ 0.0 


v 

© ORA Corp, 1992 

SL-0046 19 
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Proving termination of the loop 


Proving termination of the loop 

Loop bound annotation: 

loop bound x 2 - a 
contraction 1/4 
lower bound small 





Accurate Square Root 


function sqrt (a:= in float) return float 


begin 

return mysqrt (a, f loat 'small); 


©ORACorp, 1992 
SL-0046 
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Embedded Systems 


Want to be able to reason about computer controlled real world systems. 
Want to know what the system does in real space/time. 

The total syste can be described by logico-differential equations. 
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Formal Safety Analysis 

Nancy Leveson 
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Verification 
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To produce a verifiable and certifiable design. 
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Approaches to finding errors in requirements GENERAL APPROACH: 
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Validation on a reaiistic testbed 
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Low = v (f) < (TK 
Hi 9 k = v(I) > C*K 
TimtOvt(x) = r > t(z t) + 30 
0ut(0,x) = 0 T A(v(0) * *) 












Criterion 6.1 Every state must have a behavior (transition) defined for 
every possible input. Formally, 
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Figure 1.1: Component Communication 
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The FM9001 

Warren Hunt j 

Computational Logic, Inc. 
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Hardware Verification: What Is It? Solution Approach 
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The FM9001 Specification levels 
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Circuit Examples Translating Into LSI Logic Format 
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ALU Generator Output Summary The FM9001 Netllst 
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A hardware description language has been 
formalized. 




Derivational Techniques for Hardware 


Steve Johnson 

Indiana University 
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Deduction and Derivation... 


o have a lot in common 



o reflect common modes of reasoning 


o involve "proof engineering” 
o should be integrated 
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Digital Design Derivation system 
(DDD) 

• An interactive transformation system based on 
first-order* functional expressions 

• Specialized for digital system derivation 


DDD as a formal system 

• A core of secure algebra 
o Extensibility 
o Derivation management 



Modes of expression 



'data dm' 
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FM8501 implementation [Hunt] 

(defn I1B-MCITII (in r«i< write dtack f«tl M-*tare dat»*out 
r«(-fU< c-flag *-flag a-flag 

a-rag k-rag i*r*( ijml-M* nil-*** 

aeMTj-watt&dog-Matory oracle) 

[If (alletg aracla) 

[llat Mr reed writ* dtack raaat a«-atar* data-out rag-flla 
e-flag *-fl*f a-flag a-rag k-reg t-reg 

f[ii«l-an naltta H*n 7 *«tti 1 tt or;) 

cm-meim (a«r Mr l -rag dtack raaat 

(mi aar i-rag) 

(arita aar l-rag aa-ctora) 

(dtack (car oracla}) 

(raaat (car oracle)) 

(ao-atara aa-itara c-flag r-flag a-flag n-flag 
l-rag air) 

(data-out iati-nt a-rag k-rag c-flag l-rag but) 
(rag-flla rag-flla data-out l-rag aar i*-»*ri 
raaat) 

(aiir-nt addrout rag-flla l-rag aar raaat) 
[c-flag c-flag a-rag k-rog l-rag aar) 

(*-flag a-flag a-rag k-rag c-flag l-rag aar) 
(■-flag a-flag a-rag k-rag c-flag l-rag aar) 
(a-flag a-flag a-rag k-rag c-flag l-rag aar) 
(a-rag a-rag rlaaal-aa* rag-flla 1-rag aar raaat) 
(k-rag k-rag rlaaal-aaa rag-flla l-rag aar raaat) 
(l-rag l-rag rleaal-aea aar) 

(rlaaal-aaa raal-aaa read write aMr-a«t 
uauui j -eatck-dog-klitorf 
(dtack (car oracla)) 

(raaat (car aracla))) 

(raal-aaa raal-aaa road wrlta addr-out data-out 
•aaary - wa t e k -dog - h 1 • tary 
(dtack (car aracla)) 

(rear* (ear aracla))) 

(watek-dog raad wrlta (dtack (car oraela)) 
data-out addr-out) 

(cir aracla) 
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Physical organization of FM8501 



S 


Procedural abstraction 




define (FAC n) - (F n 1) 
where 

(F u v) - (if (zero? u) 
v 

(F (dcr u) (MPY u v))) 


define (MPY n ■) - (M n n 0) 
where 

(M v x y) - (if (zero? w) 

y 

(if (even? w) 

(M (/2 w) x (*2 y)) 

(M (/2 w) x (♦ (*2 y) x)))) 










Incorporating procedures 




Sequential Decomposition 



define (FAC n) - (F n 1 0) 
vhers 

(F u v v x) - (if (zsro? u) 
v 

(Mu v v u)) 

(M u v v x) - (if (z«ro? u) 

(F (dcr x) w 0 t) 

(if («v«n? u) 

(M (/2 u) ▼ (*2 w) x) 

(H (/2 u) ▼ (♦ (*2 v) v) x))) 


(F0 u v m dm) ■ 

(if (zero? u) 

T 

(coni (list 1 u v) 

(Ft u v (> m) (> dm)))) 

(FI u v » dm) * 

(coni (list 0 u v) 

(if (hi? (? dm)) 

(F0 (dcr u) (? ») (> ») (> dm)) 
(Ft u v (> n) (> dm)))) 


Design derivation 

Construction of an implementation by equivalence 
preserving transformations. 

£, = 3 * £, ^ ••• 


(0 maintaining the global view 
© making local transformations 
© mundane design 
0 no "complete” algebra 
0 fixes "equivalence" 

0 inhibits cleverness 






Results of Workshop Survey 


Each participant at the workshop was asked to complete a detailed survey. 1 Fifty- three people returned 
the survey; this section presents the results. 

For each question asked on the survey, the specific question is reproduced and the answers to the question 
are tabulated below. If a person circled multiple answers to a question for which only one answer was 
expected, the results were weighted. For example, in response to question 2, one Formal methods developer 
circled both b and c. This was tabulated as 0.5 for b and 0.5 for c. 

Totals or averages are given where appropriate. Not every person answered every question on the survey, 
so the totals for different questions may vary. 

1. What is the nature of your organization? 

a. University b. Formal methods developer 

c. Government d. Aerospace industry 


Question 1 

a 

b 

C 

d 

e 

Industry 

0 

0 

0 

22 

6 

Government 

0 

0 

14 

0 

0 

University 

2 

0 

0 

0 

0 

FM Developers 

0 

9 

0 

0 

0 


Note: Six people did not believe that the four listed choices accurately described the nature of their 

organization. The specific answers given were: transportation, railway transportation, non-profit 
RAD org, industry/commercial, other, and don't know. For the purpose of recording the answers, these 
6 surveys are grouped with Industry. 


2 . 


What is your primary 
a. Basic research 
d . Management 


job function? 

b, Applied research 
e. Other 


c . Product development 


Question 2 

a 

b 

c 

d 

e 

Industry 

i 

17 

5 

2 

3 

Government 

i 

5 

0 

4 

3 

University 

i 

1 

0 

0 

0 

FM Developers 

3 

1.5 

0.5 

4 

0 

Totals 

6 

24.5 

5.5 

10 

6 


3. Please rate your understanding of formal methods theory and practice: 
a. Vovice b. Somewhat familiar c. Knowledgable 

d. Considerable e. Expert 


Question 3 

a 

b 

c 

d 

e 

Industry 

8 

10 

6 

4 

0 

Government 

6 

4 

3 

0 

1 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

0 

1 

8 

Totals 

14 

14 

9 

6 

10 


1 NASA Langley personnel involved in planning and conducting the workshop did not fill out a survey. 
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Note: One of the goals of the workshop was to attract people with widely varying understanding of 

formal methods. These numbers suggest that this goal was met. 


4. 


What is the general level oi awareness o f formal methods within your organization? 
a . id* b. Minimal c. Sparse 

d. Moderate •• Considerable 


Question 4 

a 

b 

c 

d 

e 

Industry 

7 

13 

4 

1 

3 

Government 

4 

8 

1 

0 

1 

University 

0 

0 

0 

2 

0 

FM Developers 

0 

0 

1 

0 

8 

Totals 

11 

21 

6 

3 

12 


5. Before attending this workshop, how would you have rated the state-of-the-art of 
formal methods in terms of its potential for immediate application? 
a. Mot usable b. Meeds more time c. Mearly ready 

d. Ready now «. Has been ready 


Question 5 

a 

b 

c 

d 

e 

Industry 

4 

16 

4 

3 

1 

Government 

2 

5 

4 

1 

1 

University 

0 

1 

1 

0 

0 

FM Developers 

0 

0 

6 

1 

1 

Totals 

6 

22 

15 

5 

3 


Note: Three FM developers, one who answered d and two who answered c augmented their responses 

with the comment “for some applications.” 


6 . 


Mow that you’ve attended this workshop, how would you rate the state-of-the-art of 
formal methods in terms of its potential for immediate application? 
a. Mot usable b. Meeds more time c. Mearly ready 

d. Ready now e. Has been ready 


Question 6 

a 

b 

c 

d 

e 

Industry 

i 

16 

8 

3 

0 

Government 

0 

4 

6 

2 

0 

University 

0 

0 

2 

0 

0 

FM Developers 

0 

0 

7 

1 

1 

Totals 

1 

20 

23 

6 

1 


Note 1: See note for Question 5. 

Note 2: The results to this question demonstrate that the workshop did alter some people s perceptions 
of the state-of-the-art. Particularly interesting is that before the workshop, the perception of the state of 
the art by nine people was at one or the other extreme, but after the workshop, the number of people at one 
or the other extreme was reduced to two. 
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7. Please rat# the extent 
organization: 

a. lever 
d. Occasionally 


to which foraal methods is 

b. Seldom 
e. Often 


practiced today within your 

c. Sporadically 


Question 7 

a 

b 

c 

d 

e 

Industry 

15 

9 

2 

1 

i 

Government 

9 

3 

0 

2 

0 

University 

0 

0 

0 

1 

1 

FM Developers 

1 

0 

2 

1 

5 

Totals 

25 

12 

4 

5 

7 


Note: 


One FM developer answered a, and added the comment “on our 


own systems.” 


your company? 
years 


Question 8 

a 

b 

c 

d 

e 

Industry 

5 

7 

12 

3 

1 

Government 

4 

3 

3 

2 

0 

University 

1 

0 

1 

0 

0 

FM Developers 

5 

2 

1 

0 

0 

Totals 

15 

12 

17 

5 

1 


8. When do you think that formal methods will be used often in 
a. 0-2 years b. 2-5 years c. 5-10 

d. 10-20 years e. lever 


Note: An individual from industry answered c with the comment “unless required by customers 

earlier.” 


9. How difficult do you feel it is to put formal methods into practice? 
a. Extremely b. Very c. Moderately 

d. Somewhat e. Hone at all 


Question 9 

a 

b 

c 

d 

e 

Industry 

7 

9 

12 

0 

0 

Government 

2 

7 

4 

1 

0 

University 

0 

1 

1 

0 

0 

FM Developers 

2 

3 

4 

0 

0 

Totals 

11 

20 

21 

1 

0 


10. Are you personally inclined to apply formal methods on a design project in the near 
future? 

a. Strongly inclined b. Moderately inclined c. Indifferent 

d. lot inclined e. Would quit first 
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Question 10 

a 

b 

c 

d 

e 

Industry 

13 

9 

1 

5 

0 

Government 

8 

6 

0 

0 

0 

University 

2 

0 

0 

0 

0 

FM Developers 

6 

3 

0 

0 

0 

Totals 

29 

18 

1 

5 

0 


ii. How well prepared are the professionals in your organization through education and 
previous training to absorb the technology of formal methods? 
a. Minimally b. Somewhat c. Adequately 

d. Receptive •. Well prepared 


Question 11 

a 

b 

c 

d 

e 

Industry 

15 

8 

3 

0 

2 

Government 

7 

7 

0 

0 

0 

University 

0 

1 

1 

0 

0 

FM Developers 

1 

0 

0 

1 

7 

Totals 

23 

16 

4 

1 

9 


12 . 


In your organization, which of the following obstacles exist 
prevent the use of formal methods? (check all that apply) 
Management believes it is impractical 
Engineering staff believes it is impractical 

Lack of sufficient knowledge about formal methods 

Lack of required skills 

Up-front cost too high 

Have had negative experiences in the past 
Do not believe it is useful 
Vo obstacles exist 


that inhibit or 

(Mgmt) 

(Eng) 

(Know) 

(Skill) 

(Cost) 

(Neg) 

(Not) 

(None) 


Question 12 

Mgmt 

Eng 

Know 

Skill 

Cost 

Neg 

Not 

None 


Industry 

10 

13 

24 

20 

10 

4 

6 

2 

j 

Government 

5 

4 

13 

11 

6 

1 

4 

0 

| 

University 

0 

0 

1 

0 

0 

2 

0 

0 

t 

FM Developers 

1 

2 

1 

1 

3 

0 

0 

4 

j 

Totals 

16 

19 

39 

32 

19 

7 

10 

6 

§ 


Note: An industry representative checked lo obstacles exist, but added the comment “except 

funding.” 


13. How would you rate the potential benefits of using formal methods? 

a. legligible b. Somewhat useful c. Moderately useful 

d. Helpful e. Significant 
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Question 13 

a 

b 

C 

d 

e 

Industry 

0 

5 

1 

4 

18 

Government 

0 

0 

l 

4 

9 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

i 

3 

5 

Totals 

0 

5 

3 

12 

33 


Note: A person from industry circled •, but added the caveat, “ if it does all that is advertised.” 


14. How would you rate the costs of formal methods technology relative to the costs of 
current practice? 

a. Excessively higher b. Somewhat higher c. Equivalent 

d. Somewhat lower e. Much lower 


Question 14 

a 

b 

c 

d 

e 

Industry 

4 

13 

5 

4 

2 

Government 

2 

8 

0 

0.5 

1.5 

University 

0 

2 

0 

0 

0 

FM Developers 

0 

2 

5 

0 

0 

Totals 

6 

25 

10 

4.5 

3.5 


Note 1: A government representative circled e and added "over system life cycle.” 

Note 2: An industry person circled a, with the additional comment "don’t see FN replacing anything 
it only adds confidence and cost to date.” 


IS. How aggressively would you recommend your management pursue the use of formal 
methods technology? 

a. Forget it 

b. Keep up with developments 

c. Attempt small pilot projects 

d. Attempt larger applications 

e. Full speed ahead 


Question 15 

a 

b 

c 

d 

e 

Industry 

0 

6 

20 

2 

0 

Government 

0 

0.5 

10.5 

2 

1 

University 

0 

0 

2 

0 

0 

FM Developers 

0 

0.5 

2 

4.5 

1 

Totals 

0 

7 

34.5 

8.5 

2 


Note: One industry representative answered c and added the comment “to completion!” 


16. How much empirical evidence on the benefits of formal methods do you feel is 
available for managers to make informed decisions regarding its use? 
a. Insufficient b. I early sufficient c. Adequate 

d. More than adequate e. Plentiful 
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Question 16 

a 

b 

c 

d 

e 

Industry 

22 

2 

3 

0 

1 

Government 

8 

2 

3 

0 

0 

University 

1 

0 

1 

0 

0 

FM Developers 

4 

3 

0 

0 

2 

Totals 

35 

7 

7 

0 

3 


17. Rats tha importance of reusable formal verifications such as verified clock 
synchronization circuits and verified software modules, 
a. lone at all b. Somewhat c. Moderately 

d. Very s. Extremely 


Question 17 

a 

b 

c 

d 

e 

Industry 

2 

2 

7 

6 

10 

Government 

0 

5 

4 

3 

0 

U ni versity 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

0 

4 

4 

Totals 

2 

7 

11 

14 

15 


18. Rate the importance of generic tools (such as, semi-automatic theorem provers, 
specification language typecheckers) that can be applied to software/hardware 
development. 

a. lone at all b. Somewhat c. Moderately 

d. Very #. Extremely 


Question 18 

a 

b 

c 

d 

e 

Industry 

0 

2 

5 

11 

10 

Government 

0 

1 

4 

6 

3 

University 

0 

0 

0 

0 

2 

FM Developers 

0 

0 

2 

2 

5 

Totals 

0 

3 

11 

19 

20 


19. Rate the importance of the capability of formal methods to produce trustworthy 
solutions of difficult problems in computer science, 
a. Wone at all b* Somewhat c. Moderately 

d. Very a. Extremely 


Question 19 

a 

b 

c 

d 

e 

Industry 

i 

3 

5 

12 

7 

Government 

0 

1 

4 

4 

5 

University 

0 

1 

0 

1 

0 

FM Developers 

0 

0 

1 

2 

6 

Totals 

1 

5 

10 

19 

18 
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Note: An industry person wrote: "(a) who cares (practically) about CS? (c) lor real problems. 
We need trustworthy solutions to real problems!” 


20. Where in the life-cycle do you feel formal methods can be applied most cost- 
effectively? 

a. Requirements b. High-level design c. Detailed design 

d. Implementation e. Maintenance 


Question 20 

a 

b 

c 

d 

e 

Industry 

15.5 

8 

3.5 

0.5 

0.5 

Government 

9.33 

2.83 

1.33 

0.5 

0 

University 

0.45 

0.45 

0.45 

0.45 

0.20 

FM Developers 

1.67 

5.67 

0.33 

0 

0.33 

Totals 

26.95 

16.95 

5.61 

1.45 

1.03 


21. Where in the life-cycle do you feel formal methods can yield the most significant 
benefits » irrespective of cost? 

a. Requirements b. High-level design c. Detailed design 

d. Implementation e. Maintenance 


Question 21 

a 

b 

c 

d 

e 

Industry 

20.33 

2.83 

3.33 

0 

0.5 

Government 

9.33 

1.83 

0.83 

0 

0 

University 

1.33 

0.33 

0.33 

0 

0 

FM Developers 

1.5 

1.5 

3 

1 

1 

Totals 

32.5 

6.5 

4.5 

1 

1.5 


22 . 


How long does it take 
a. Less than 2 weeks 
d. 6 months to 1 year 


to become proficient in formal methods? 

b. 2 weeks to 1 month c. 1 to 6 months 
e. 1 to 6 years 


Question 22 

a 

b 

c 

d 

e 

Industry 

0 

0 

2 

16 

9 

Government 

0 

0 

1 

5 

6 

University 

0 

0 

0 

0 

2 

FM Developers 

0 

0 

1 

7 

0 

Totals 

0 

0 

4 

28 

17 


Note 1: Two people, one from government and one from industry, said that the answer to this question 
was "dependent on background.” 

Note 2: A person from a university circled e, and annotated the answer with "or more.” 


23. What is your opinion of the following statement: ''Proficiency in formal methods 
requires a high degree of mathematical sophistication . 9 * ? 
a. Agree strongly b. Agree c. Vo opinion 

d. Disagree e. Disagree strongly 
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Question 23 

a 

b 

c 

d 

e 

Industry 

9 

14 

1 

2 

2 

Government 

5 

6 

1 

i 

0 

University 

0 

1 

0 

i 

0 

FM Developers 

0 

6 

0 

2 

0 

Totals 

14 

27 

2 

6 

2 


Note: An industry representative circled &, but added, “but it shouldn’t b« the case 


24 To «ach of ths following areas assign a number from i to 6 to denote the importance 
of the area. Use 1 to denote that the area is extremely important, and 5 to denote 
that the area is not important at all. Please assign a 0 to any area about which 

you hav« no opinion. 

Basic modeling techniques 

Code verification (especially for Ada) 

Education and training 

Integrated verification systems 

Mechanical theorem provers 

Reusable deductive theories (libraries of definitions and theories) 

Reusable, verified software libraries 

Special purpose verification tools (such as Spectool, DDD, k Penelope) 

Specification languages 

Worked examples 


Question 24: Industry 
0 1 

2 

3 

4 

5 

Avg. 

Model. Tech. 

3 

11 

8 

4 

2 

0 

1.9 

Code Verif. 

4 

10 

5 

6 

3 

0 

2.1 

Education 

2 

15 

10 

0 

0 

1 

1.5 

Int. Ver. Sys. 

4 

10 

6 

5 

3 

0 

2.0 

Mech. T. Prov. 

4 

2 

11 

7 

4 

0 

2.5 

R. Ded. Theo. 

5 

5 

11 

3 

4 

0 

2.3 

R. Soft. Lib. 

2 

7 

11 

3 

5 

0 

2.2 

Sp. Purp. Tool 

5 

0 

7 

14 

2 

0 

2.8 

Spec. Langs. 

1 

14 

8 

3 

1 

1 

1.8 

Examples 

2 

11 

9 

4 

2 

0 

1.9 


Question 24: Government 

0 12 3 

4 

5 

Avg. 

Model. Tech. 

2 

5 

4 

0 

0 

2 

2.1 

Code Verif. 

2 

4 

2 

5 

0 

1 

2.3 

Education 

0 

6 

0 

5 

0 

2 

2.4 

Int. Ver. Sys. 

3 

0 

2 

4 

2 

1 

3.2 

Mech. T. Prov. 

1 

3 

2 

3 

1 

2 

2.7 

R. Ded. Theo. 

2 

1 

2 

4 

3 

1 

3.1 

R. Soft. Lib. 

1 

2 

2 

4 

3 

1 

2.9 

Sp. Purp. Tool 

4 

1 

2 

4 

1 

1 

2.9 

Spec. Langs. 

1 

4 

3 

2 

1 

2 

2.5 

Examples 

1 

6 

2 

2 

0 

2 

2.2 
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Question 24: University 
0 12 

3 

4 

5 

Avg. 

Model. Tech. 

i 

1 

0 

0 

0 

0 

1.0 

Code Verif. 

0 

0 

0 

0 

0 

0 

— 

Education 

0 

0 

0 

0 

0 

0 

— 

Int. Ver. Sys. 

0 

0 

0 

0 

0 

0 

— 

Mech. T. Prov. 

0 

0 

0 

0 

0 

0 

“ 

R. Ded. Theo. 

0 

0 

0 

0 

0 

0 

— 

R. Soft. Lib. 

0 

0 

0 

0 

0 

0 

— 

Sp. Purp. Tool 

0 

0 

0 

0 

0 

0 

— 

Spec. Langs. 

0 

0 

0 

0 

0 

0 


Examples 

0 

0 

0 

0 

0 

0 

I 


Question 24: FM Developers 
0 12 3 4 

5 

Avg. 

Model. Tech. 

0 

6 

2 

1 

0 

0 

1.4 

Code Verif. 

0 

3 

2 

2 

1 

1 

2.4 

Education 

0 

6 

2 

1 

0 

0 

1.4 

Int. Ver. Sys. 

0 

5 

1 

2 

1 

0 

1.9 

Mech. T. Prov. 

0 

3 

3 

2 

1 

0 

2.1 

R. Ded. Theo. 

0 

3 

6 

0 

0 

0 

1.7 

R. Soft. Lib. 

0 

4 

2 

4 

0 

0 

2.0 

Sp. Purp. Tool 

0 

3 

2 

1 

3 

0 

2.4 

Spec. Langs. 

0 

3 

6 

0 

0 

0 

1.7 

Examples 

0 

5 

2 

1 

1 

0 

1.8 


Note 1: Answers of 0 were ignored in calculating the averages. - 

Note 2: For a few respondents, the answers to this question seemed inconsistent with answers to other 

questions. We suspect that some people may have failed to read the question carefully, and as a result reversed 
the ordering (that is, used 6 to denote extreme importance and 1 to denote no importance); however, we 
recorded their responses as given. 


25. To each ol the following tools and techniques assign a number from 1 to 
5 to denote your perception of the usefulness of the tool/technique. Use 
1 to denote that you believe the tool/technique may be extremely useful, 
and 5 to denote that you believe the tool/technique is useless. Please 
assign a 0 to any tool/technique about which you have no opinion. 


Boyer-Moore 

HOL 

Penelope 

Spectool 


DDD 

Hodelisation 
PVS/Ehda 


EVES 

luprl 

Safety analysis 
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Question 25: Industry 
0 1 

2 

3 

4 

5 

Avg. 

Boyer-Moore 

9 

1 

4 

10 

3 

1 

2.9 

HOL 

8 

1 

7 

6 

5 

1 

2.9 

Penelope 

12 

0 

9 

4 

3 

0 

2.6 

Spectool 

16 

0 

6 

4 

2 

0 

2.7 

DDD 

19 

0 

2 

4 

3 

0 

3.1 

Modelisation 

14 

5 

2 

3 

2 

2 

2.6 

PVS/Ehdm 

5 

6 

10 

5 

1 

1 

2.2 

EVES 

20 

0 

3 

3 

1 

1 

3.0 

Nuprl 

23 

0 

3 

0 

1 

1 

3-0 

Safety Analysis 

8 

14 

3 

2 

1 

0 

1.5 


Question 25: Government 

0 1 2 3 4 5 1 Avg. 


Boyer-Moore 7 1 3 2 0 0 

HOL 820300 

Penelope 11 1 1 000 1-5 

Spectool 13 0 0 0 0 0 

DDD 12 0 1 0 0 0 

Modelisation 8 1 2 0 0 0 

PVS/Ehdm 7 3 1 2 0 0 

EVES 12 0 0 1 0 0 3.0 

Nuprl 12 0 0 1 0 0 3.0 

Safety Analysis 5 5 110 1 1.9 


Question 25: University 

0 1 2 3 4 5 | Avg. 


Boyer-Moore 0 1 10 0 0 

HOL 002000 

Penelope 10 10 0 0 

Spectool 1 0 1 0 0 0 2.0 

ODD 1 0 1 0 0 0 2.0 

Modelisation 2 0 0 0 0 0 

PVS/Ehdm 0 2 0 0 0 0 1.0 

EVES 0 0 1 1 0 0 2.5 

Nuprl 0 0 2 0 0 0 2.0 

Safety Analysis 1 0 0 0 1 0 4.0 
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Note: See the notes for Question 24. 


26. How expressive should a formal language be? 

a. Very expressive (such as Z and VDM) b. To the level of higher-order logic 

c. To the level of 1st order logic d. To the level of Prolog 

e. To the level of propositional calculus 


Question 26 

a 

b 

c 

d 

e 

Industry 

14 

6 

2 

1 

0 

Government 

2 

4 

0 

0 

1 

University 

1 

0.5 

0.5 

0 

0 

FM Developers 

3 

4 

2 

0 

0 

Totals 

20 

14.5 

4.5 

1 

1 


Note: Four people, one from industry and three from government, did not answer this question, but 

wrote the following comments instead: “depends on application,” “to understanding of user,” “this 
needs to be decided on the basis of the domain of application requirements,” and “depends on 
when it is used.” 


27. How important is it to have a specification language that can mimic the notation 
typically employed in the problem domain? 

a. Hone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 27 

a 

b 

C 

d 

e 

Industry 

0 

3 

5 

12 

6 

Government 

0 

2 

3 

2 

5 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

3 

4 

2 

Totals 

0 

5 

11 

19 

14 


Note 1: A member of the government answered e, and included the comment: “to be accepted by 

the engineers and program managers.” 

Note 2: Another government representative did not circle an answer, but wrote “It must not necessarily 
mimic but must be readable by experts in the problem domain.” 


28. How important is the availability of powerful decision procedures in a theorem 
prover (for example, decision procedures for linear arithmetic and propositional 
calculus)? 

a. lone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 28 

a 

b 

C 

d 

e 

Industry 

0 

3 

8 

7 

5 

Government 

0 

1 

3 

3 

2 

University 

0 

0 

1 

1 

0 

FM Developers 

0 

0 

1 

2 

6 

Totals 

0 

4 

13 

13 

13 


. i 


! 


t- 
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29 . 


To each of the following areas assign a number from 1 to S to denote your opini 
as to the importance of NAS* sponsoring work in the area. Use 1 to denote that you 
believe it is extremely important for NASA to sponsor work in the area, and 5 to 
denote that you believe NASA should not sponsor any work in the area. 

Theoretical research (for example, developing theorem provers) 

Applied research (for example, pilot projects applying formal methods) 

■" j 0 i n t projects between traditional engineering groups and formal methods experts 

Workshops such as this one 


Question 29: Industry 

0 

1 

2 

3 

4 

5 

Avg. 

'Theoretical Research 

0 

8 

r> 

7 

3 

r> 

2.7 

Applied Reaearcli 

0 

19 

0 

0 

0 

3 

1.6 

Joint Projects 

0 

23 

2 

2 

1 

0 

1.3 

Workshops 

0 

17 

7 

2 

2 

0 

1.6 


Question 29: Government 

0 12 3 4 

5 

Avg. 

'Theoretical Research 

0 

3 5 1 4 

0 

2.5 

Applied Research 

0 

10 1 1 o 

1 

1.5 

Joint Projects 

0 

9 3 0 1 

0 

1.5 

Workshops 

0 

11 1 0 0 

1 

1.4 


" Question 29: University 
0 1 

2 

3 

4 

5 

Avg. 

Theoretical Research 

0 

0 

1 

1 

0 
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Note: See the notes for Question 24. 


Questions 30-32 were not multiple choice. Only a few representative comments from each organizational 
category are included below. These comments are presented exactly as given; no editing has been done. For 
those questions, Government and University participants have been grouped together. 


30. What formal methods have you used? 

Industry: Boyer-Moore, clcanroom, Clio, EIIDM, MOL, Spedool, temporal logic, VDM, Z 

Gov & Univ: Boyer-Moore, cleanroom, ODD, Ell DM, MOL, VDM 
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FM Developers; Boyer-Moore, Clio, EHDM, EVES, HOL, PVS, Penelope, SDVS, Spectool, temporal 
logic, Z 


31. In what applications and parts of the life-cycle have yon used formal methods? 

Industry: requirements modeling, design, and testing, conceptual study, detailed design, verification of 

algorithms, implementation 

Gov & Univ: software requirements, high level requirements, avionics software, missile systems, electronic 

message systems, design, implementation, academic research projects 

FM Developers: hardware designs, microcode, detailed design, algorithms, high-level HW design 


32. Any additional comments? 

Industry: 

• ''Workshops of this type where interested industries can attend and participate are 
excellent opportunities for technology transfer. I would encourage VASA to continue 
this type of interaction . 9 * 

• "I would very much like to see a survey of (1) methods (2) languages k (3) tools 
presenting PROs k COVs of each. As a novice wanting to enter the field , where do 
I start ? 9 1 

• f 'Tools are very important to this effort. Paper and pencil will not spread to industry. 1 

• "It would have been nice to actually solve some simple problems using a formal technique 
rather than seeing lots of talks about proofs." 

e "Suitable applications of FNs was not elaborated on. I still cannot say 'where 1 
one should apply 'what 1 FM. * 1 

• "leed to separate HW FM’s from SW FM’s." 

• "This is one of the only forums I have attended that has had equal representation 
from the software and hardware community sharing roughly equal concerns and a common 
interest in a technology of equal value and benefit to each community." 

e "You are overcautious about overselling. ..." 

Gov & Univ: 

• "We must find a way to better find errors in Reqm’ts" 

• "It is important for VASA to take a leadership position in Formal Methods for civilian 
aerospace applications . * 1 

e "FM appears to be currently the most feasible means of adding rigor and consistency 
to the software development process." 

• "Keep holding this workshop!" 

• "I really wish copies of slides had been available at the conference. It would greatly 
simplify notetaking." 

FM Developers: 

• "There is no 'royal road* to FM for industry." 

e "FM is powerful for educating designers." 

• "Formal methods are no panacea" 
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